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Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Committee Terrestrial Trunked Radio 
(TETRA). 

The present document is part 7of a multi-part deUverable covering the Voice plus Data (V+D), as identified below: 

EN 300 392-1 : "General network design"; 

EN 300 392-2: "Air Interface (AI)"; 

EN 300 392-3: "Interworking at the Inter-System Interface (ISI)"; 

ETS 300 392-4: "Gateways basic operation"; 

EN 300 392-5: "Peripheral Equipment Interface (PEI)"; 

EN 300 392-7: "Security"; 

EN 300 392-9: "General requirements for supplementary services"; 

EN 300 392-10: "Supplementary services stage 1"; 

EN 300 392-11: "Supplementary services stage 2"; 

EN 300 392-12: "Supplementary services stage 3"; 

ETS 300 392-13: "SDL model of the Air Interface (AI)"; 

ETS 300 392-14: "Protocol Implementation Conformance Statement (PICS) proforma specification"; 

TS 100 392-15: "TETRA frequency bands, duplex spacings and channel numbering"; 

TS 100 392-16: "Network Performance Metrics"; 

TR 100 392-17: "TETRA Vh-D and DMO specifications"; 

TS 100 392-18: "Air interface optimized applications". 

NOTE: Part 10, sub-part 15 (Transfer of control), part 13 (SDL) and pait 14 (PICS) of this multi-part dehverable 
are in status "historical" and are not maintained. 

Introduction 

The present document shall be withdrawn within 12 months of publication in favour of an update to EN 300 392-7. 
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Scope 



The present document defines the Terrestrial Trunked Radio system (TETRA) supporting Voice plus Data (V+D). It 
specifies the air interface, the inter-working between TETRA systems and to other systems via gateways, the terminal 
equipment interface on the mobile station, the connection of line stations to the infrastructure, the security aspects in 
TETRA networks, the management services offered to the operator, the performance objectives, and the supplementary 
services that come in addition to the basic and teleservices. 

The present part describes the security mechanisms in TETRA V+D. It provides mechanisms for confidentiality of 
control signalling and user speech and data at the air interface, authentication and key management mechanisms for the 
air interface. 



1.1 Security classes 



TETRA security is defined in terms of class. Each class has associated features that are mandatory or optional and are 
summarized in table 1 . 

Table 1 : Summary of Security features in TETRA by class 



Class 


Authentication 


OTAR 


Encryption 


Enable-Disable 




Clause 4 


Clause 4 


Clause 6 


Clause 5 


1 






(see note 3) 


- 





2 








M 





3 


M 
(see note 1) 


M 
(see note 2) 


M 


ot 


KEY: M = Mandatory 
= Optional 
- = Does not apply 
t = Recommended 


NOTE 1 : Authentication is required for generation of DCK. 

NOTE 2: OTAR for CCK is mandatory, other key management OTAR mechanisms are optional. 
NOTE 3: Required if key material is either distributed in preparation for security class transition, or during cell 
reselection to a cell of a different security class. 



The present document describes a system in which all signalling and traffic within that system comply with the same 
security class. However, signalling permits more than one security class to be supported concurrently within a SwMI, 
and movements between these classes are described in the present document. The SwMI shall control the state of AI 
encryption. 

An MS may support one, several, or all security classes. Each cell shall support at any one time one of the following 
options: 

class 1 only; 

class 2 only; 

class 2 and class 1; 

class 3 only; or 

class 3 and class 1. 

Class 2 and class 3 are not permitted to be supported at the same time in any cell. 
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1 .2 Document layout 



Clause 4 describes the authentication and key management mechanisms for the TETRA air interface. The following two 
authentication services have been specified for the air-interface in ETR 086-3 (see bibliography), based on a threat 
analysis: 

• authentication of an MS by the TETRA infrastructure; 

• authentication of the TETRA infrastructure by an MS. 

Clause 5 describes the mechanisms and protocol for enable and disable of both the mobile station equipment and the 
mobile station user's subscription. 

Air interface encryption may be provided as an option in TETRA. Where employed, clause 6 describes the 
confidentiality mechanisms using encryption on the air interface, for circuit mode speech, circuit mode data, packet data 
and control information. Clause 6 describes both encryption mechanisms and mobility procedures. It also details the 
protocol concerning control of encryption at the air interface. 

The present document does not address the detail handling of protocol errors or any protocol mechanisms when TETRA 
is operating in a degraded mode. These issues are implementation specific and therefore fall outside the scope of the 
TETRA standardization effort. 

The detail description of the Authentication Centre is outside the scope of the present document. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Authentication Code (AC): (short) sequence to be entered by the user into the MS that may be used in addition to the 
UAK to generate K with algorithm TB3 

authentication Key (K): primary secret, the knowledge of which has to be demonstrated for authentication 

authentication session: period between consecutive successful authentication operations 

CCK Identifier (CCK-id): identification of the key within an LA 

cipher key: value that is used to determine the transformation of plain text to cipher text in a cryptographic algorithm 

cipher text: data produced through the use of encipherment 

NOTE: The semantic content of the resulting data is not available (see ISO 7498-2 [3]). 

class: See security class. 

Common Cipher Key (CCK): cipher key that is generated by the infrastructure to protect group addressed signalling 
and traffic 

NOTE: CCK is also used to protection of SSI identities (ESI) in layer 2. 

Crypto Management Group (CMG): group of MSs with common key material 

decipherment: reversal of a corresponding reversible encipherment (see ISO 7498-2 [3]) 

Derived Cipher Key (DCK): key generated during authentication for use in protection of individually addressed 
signalling and traffic 

encipherment: cryptographic transformation of data to produce cipher text (see ISO 7498-2 [3]) 

Encryption Cipher Key (ECK): cipher key that is used as input to the encryption algorithm 

NOTE: This key is derived from one of SCK, DCK, MGCK or CCK and modified using an algorithm by the 
broadcast data of the serving cell. 

encryption mode: choice between static (SCK) and dynamic (DCK/CCK) encipherment 

encryption state: encryption on or off 

end-to-end encryption: encryption within or at the source end system, with the corresponding decryption occurring 
only within or at the destination end system (defined in EN 302 109 [6]) 

Extended Group Session Key for OTAR (EGSKO): cipher key used for distribution of keys to groups of MSs 

fallback SCK: key used by class 3 system when operating in class 2, for example in a fault or fallback situation 

Group Cipher Key (GCK): cipher key known by the infrastructure and MS to protect group addressed signalling and 
traffic 

NOTE: Not used directly at the air interface but modified by CCK to give a Modified Group Cipher Key 
(MGCK). 

Group Session Key for OTAR (GSKO): cipher key used to derive EGSKO for the distribution of keys to groups of 
MSs 

Initialization Value (IV): sequence of symbols that randomize the KSG inside the encryption unit 

key association group: set of keys associated with one GSSI at different periods of time 
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key stream: pseudo random stream of symbols that is generated by a KSG for encipherment and decipherment 

Key Stream Generator (KSG): cryptographic algorithm which produces a stream of binary digits, which can be used 
for encipherment and decipherment 

NOTE: The initial state of the KSG is determined by the IV value. 

Key Stream Segment (KSS): key stream of arbitrary length 

Location Area identifier (LA-id): unique identifier within a SwMI of a location area 

Manipulation Flag (MF): flag used to indicate that a sealed cipher key (CCK, SCK, GCK or GSKO) has been 
incorrectly recovered 

Modified Group Cipher Key (MGCK): cipher key known by the infrastructure and MS to protect group addressed 
signalling and traffic that is composed algorithmically from CCK and GCK 

Over The Air Re-keying (OTAR): method by which the SwMI can transfer secret keys securely to terminals 

Personal Identification Number (PIN): entered by the user into the MS and used to authenticate the user to the MS 

plain text: un-encrypted source data 

NOTE: The semantic content is available. 

proprietary algorithm: algorithm which is the intellectual property of a legal entity 

Random Challenge (RANDl, RAND2): random value generated by the infrastructure to authenticate an MS or in an 
MS to authenticate the infrastructure, respectively 

Random Seed (RS): random value used to derive a session authentication key from the authentication key 

Random seed for OTAR (RSO): random value used to derive a session key for OTAR from an MS's authentication 
key 

Registered Area (RA): collection of Location Areas (LA) to which the MS may perform cell re-selection without need 
for explicit invocation of the registration protocol 

Response (RESl, RES2): value calculated in the MS from RANDl and the KS to prove the authenticity of an MS to 
the infrastructure or by the infrastructure from RAND2 and the KS' to prove its authenticity to an MS, respectively 

SCK-set: collective term for a group of up to 32 SCK which may be held by an MS 

Sealed Cipher Key (SxCK): cipher key that has been cryptographically protected 

security class 1, 2 or 3: classification of terminal and SwMI encryption and authentication support (see table 1) 

NOTE: In the above definition x refers to Common, Group, Static. 

Session Authentication Key (KS, KS'): generated from the authentication key and a random seed for authentication 

NOTE: It has a more limited lifetime than the authentication key and can be stored in less secure places and 
forwarded to visited networks. 

Session Key for OTAR (KSO): derived from a MS's authentication key and a random seed for OTAR 

NOTE: KSO is used to protect the transfer of the Static Cipher Key. 

Static Cipher Key (SCK): predetermined cipher key that may be used to provide confidentiality in class 2 systems 
with a corresponding algorithm and may also be used in DMO or for fallback 

TETRA algorithm: mathematical description of a cryptographic process used for either of the security processes 
authentication or encryption 

time stamp: sequence of symbols that represents the time of day 

User Authentication Key (UAK): key stored in a (possibly detachable) module within the MS and used to derive the 
authentication key (with or without a PIN as an additional parameter) 
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3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AC Authentication Code 

AESI Alias Encrypted Short Identity 

AI Air Interface 

ASSI Alias Short Subscriber Identity 

BNCH Broadcast Network CHannel 

BS Base Station 

CC Colour Code 

CCK Common Cipher Key 

CCK-id CCK-identifier 

CK Cipher Key 

CMG Crypto Management Group 

CN Carrier Number 

C-PLANE Control-PLANE 

DCK Derived Cipher Key 

NOTE: DCKl and DCK2 are components of the Derived Cipher Key. 

DMO Direct Mode Operation 

DM-SCK SCK used in Direct Mode operation 

ECK Encryption Cipher Key 

EGSKO Extended Group Session Key for OTAR 

ESI Encrypted Short Identity 

FACCH Fast Associated Control CHannel 

EEC Forward Error Correction 

GCK Group Cipher Key 

GCKN Group Cipher Key Number 

GCK-VN GCK- Version Number 

GESI Group Encrypted Short Identity 

GSKO Group Session Key for OTAR 

GSKO-VN GSKO-Version Number 

GSSI Group Short Subscriber Identity 

GTSI Group TETRA Subscriber Identity 

lESI Individual Encrypted Short Identity 

ISSI Individual Short Subscriber Identity 

ITSI Individual TETRA Subscriber Identity 

IV Initialization Value 

K authentication Key 

KAG Key Association Group 

KS, KS' Session authentication Key 

KSG Key Stream Generator 

KSO Session Key for OTAR 

KSS Key Stream Segment 

LA Location Area 

LA-id Location Area-identifier 

LLC Logical Link Control 

MAC Medium Access Control 

MF Manipulation Flag 

MGCK Modified Group Cipher Key 

MLE Mobile Link Entity 

MM Mobility Management 

MS Mobile Station 

MSC Message Sequence Chart 

OTAR Over The Air Re-keying 

PDU Protocol Data Unit 

PIN Personal Identification Number 

RA Registered Area 

RANDl RANDom challenge 1 

RAND2 RANDom challenge 2 
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RESl RESponse 1 

RES2 RESponse 2 

RS Random Seed 

RSO Random Seed for OTAR 

SACCH Slow Associated Control CHannel 

SAP Service Access Point 

SCCK Sealed Common Cipher Key 

SCH Signalling CHannel 

SCH/F Full Slot Signalling CHannel 

SCH/HD Half-slot Downlink Signalling CHannel 

SCH/HU Half-slot Uplink Signalling CHannel 

SCK Static Cipher Key 

SCKN Static Cipher Key Number 

SCK-VN SCK- Version Number 

SDMO Secure Direct Mode Operation 

SDU Service Data Unit 

SGCK Sealed GCK 

SGSKO Sealed GSKO 

SMI Short Management Identity 

SSCK Sealed SCK 

SSI Short Subscriber Identity 

STCH STeaHng CHannel 

SwMI Switching and Management Infrastructure 

TCH Traffic CHannel 

TCH/2.4 Traffic CHannel for 2,4 kbs circuit mode data 

TCH/4.8 Traffic CHannel for 4,8 kbs circuit mode data 

TCH/7.2 Traffic CHannel for 7,2 kbs circuit mode data 

TEA TETRA Encryption Algorithm 

NOTE: Used with specific numeric algorithm identity e.g. TEAL 

TEI TETRA Equipment Identity 

TMO Trunked Mode Operation 

TM-SCK SCK used in Trunked Mode operation 

TNMM TETRA Network Mobility Management (refers to the SAP) 

UAK User Authentication Key 

U-PLANE User-PLANE 

USSI Unexchanged Short Subscriber Identity 

XRES 1 expected RESponse 1 

XRES2 expected RESponse 2 



4 Air Interface authentication and key management 

mechanisms 

Authentication is optional, however, if it is used it shall be as described in this clause. 



4.1 



Air interface authentication mechanisms 



4.1.1 



Overview 



The authentication method described is a symmetric secret key type. In this method one secret, the authentication key, 
shall be shared by each of the authenticating parties, and there should be strictly two parties with knowledge of the 
secret. Authentication shall be achieved by the parties proving to each other knowledge of the shared secret. 
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The authenticating parties shall be the authentication centre of the Switching and Management Infrastructure (SwMI) 
and the Mobile Station (MS). The MS is considered, for the purposes of authentication, to represent the user as defined 
by the Individual TETRA Subscriber Identity (ITSI). The design of the SwMI is not specified, but some other entity 
such as a Base Station (BS) may carry out the authentication protocol on behalf of the Authentication Centre. This 
entity is assumed to be trusted by the SwMI and the authentication exchange proves knowledge given to this entity by 
the authentication centre. This knowledge shall be the session authentication key (KS). This ensures that the 
authentication key K of the MS is never visible outside the Authentication Centre. 

Authentication and provision of keys for use at the air interface shall be linked by the use of a common algorithm set. 
This algorithm set shall include a means of providing cipher keys over the air interface. The controlling party in all 
authentication exchanges shall be the SwMI. 

NOTE: The SwMI controls access to the network and not the authentication process (i.e. successful 
authentication is not sufficient to guarantee access to the SwMI). 

The authentication process describes a confirmed 2-pass challenge-response protocol. 

It is assumed that the intra-system interface linking the authenticating entity to the authentication centre is adequately 
secure. 

4.1 .2 Authentication of an MS 

In this clause, a mechanism is described that shall be used to achieve the authentication of an MS by the SwMI. This 
shall be done using a challenge response protocol, with a session authentication key (KS) derived from an 
authentication key that shall be shared by the MS and the infrastructure. The session authentication key shall be 
provided by an authentication centre of the home system. 

The computation of the session authentication key shall be carried out by an algorithm, TAl 1 . The computation of the 
response shall be done by another algorithm, TA12, which at the same time shall produce a derived cipher key. 

The SwMI shall generate a random number as a challenge RANDl. The MS shall compute a response, RESl, and the 
SwMI shall compute an expected response, XRES 1 . A component of the derived cipher key shall be generated by this 
process, labelled DCKl. The SwMI on receipt of RESl from the MS shall compare it with XRESl. If the values are 
equal the result Rl shall be set to TRUE, else the result Rl shall be set to FALSE. 

The process is summarized in figure 1 . 
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Figure 1 : Authentication of a lUIS by thie infrastructure 
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4.1 .3 Authentication of tine infrastructure 

Authentication of the infrastructure by a MS shall be carried out in the same way as described in clause 4.1.2 with the 
roles of the challenger and challenged reversed. The MS shall generate a challenge, RAND2, the SwMI shall generate 
an actual response, RES2, and the MS shall generate an expected response, XRES2. A component of the derived cipher 
key shall be generated by this process, labelled DCK2. The MS on receipt of RES2 from the SwMI shall compare it 
with XRES2. If the values are equal the result R2 shall be set to TRUE, else the result R2 shall be set to FALSE. 

The same authentication key K shall be used as in the case of authentication of the MS by the infrastructure together 
with a random seed RS. However, the algorithms shall be different: TAl 1 shall be replaced by TA21 and TA12 by 
TA22. Hence, there should also be a different value for the session authentication key, KS'. The process is summarized 
in figure 2. 
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Figure 2: Authentication of the infrastructure by a IVIS 

4.1 .4 Mutual autinentication of MS and infrastructure 

Mutual authentication of MS and infrastructure shall be achieved using a confirmed three pass mechanism. The 
algorithms and key K used shall be the same as those used in the one way authentication described in the previous 
clauses. The decision to make the authentication mutual shall be made by the first party to be challenged, not the initial 
challenging party. Thus mutual authentication shall be started as a one way authentication by the first challenging party, 
and then made mutual by the responding party. 

If the first challenging party does not support mutual authentication, then it may immediately conclude the 
authentication exchange by indicating a successful authentication result to the responding party. When the MS is the 
responding party, it determines whether or not to remain on the serving cell. 

In the event that the first authentication fails, the second authentication shall be abandoned. However, if the first 
challenge is ignored by the initial challenged party, then the initial challenged party may instead challenge the initial 
challenging party. When the MS is the initial challenging party, it determines whether or not to remain on the serving 
cell. 
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If the authentication was initiated by the SwMI, it shall use K and one random seed RS with algorithms TAl 1 and 
TA21 to generate the pair of session keys KS and KS'. It shall then send random challenge RANDl to the MS together 
with random seed RS. The MS shall run TAl 1 to generate session key KS, and because the authentication is to be made 
mutual it shall also run algorithm TA21 to generate a second session key KS'. Both MS and SwMI shall run algorithm 
TA12; the MS then sends its response RESl back to the SwMI. However, the MS also sends its mutual challenge 
RAND2 to the SwMI at the same time. The SwMI shall compare the response from the MS RESl with its expected 
response XRESl, and because it has received a mutual challenge, it shall run TA21 to generate session key KS' if it has 
not already done so. The SwMI shall then run TA22 to produce its response to the MS's challenge RES2. RES2 is sent 
to the MS, which shall also run TA22 to produce expected response XRES2. The MS on receipt of RES2 from the 
SwMI shall compare it with XRES2. If the values are equal the result R2 shall be set to TRUE, else the result R2 shall 
be set to FALSE. If R2 is TRUE mutual authentication will have been achieved. 

Algorithms TA12 and TA22 produce DCKl and DCK2 respectively; these shall be combined in TB4 by both MS and 
SwMI to produce a DCK which has therefore been created as a result of challenges by both parties. The algorithm TB4 
is described in clause 4.2.1. 

The process is shown in figure 3. 
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Figure 3: Mutual authentication initiated by SwIUII 

The mutual authentication process may also occur if a one way authentication is initiated by the MS, and then made 
mutual by the SwMI. In this case, the algorithms are the same, however, the sequence is reversed as shown in figure 4. 
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Figure 4: Mutual authentication initiated by lUIS 

4.1 .5 The authentication key 

The ITSI and its associated user should be authenticated by a process that is carried out in the MS, as described in 
clause 4.1.2. To provide against misuse of lost, or stolen, MS, and to authenticate the user to the MS, the user should be 
required to make an input before K is available and valid for use. K may be stored in a module, which may or may not 
be detachable, and the user may be required to make an input to this module, e.g. a personal identification number 
(PIN). 

4.1 .6 Equipment authentication 

The authentication of the TETRA Equipment Identity (TEI) is outside the scope of the present document. However, the 
protocol described in clause 4.4 provides a mechanism whereby the BS may demand an MS to provide TEI as part of 
the registration exchange. 
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4.2 Air Interface key management mechanisms 

Five types of key are managed over the air interface: 

• the Derived Cipher Key (DCK); 

• the Common Cipher Key (CCK); 

• the Group Cipher Key (GCK); 

• the Group Session Key for OTAR (GSKO); and 

• the Static Cipher Key (SCK). 

The ESI mechanism is also described in this clause. Exchange of DCK is linked to the authentication exchange 
described in clause 4.1. Clauses 4.2.2 to 4.2.5 describe over the air re-keying (OTAR) that is used to exchange the 
remainder of these keys. 

4.2.1 The DCK 

DCK applies only to class 3 cells for encryption. 

If DCK is used for key sealing (OTAR CCK, see clause 4.2.3) the DCK should be always be generated irrespective of 
the security class of the cell. 

Successful authentication of the MS or the infrastructure shall result in the generation of DCKl or DCK2, respectively. 
Mutual authentication shall generate both DCKl and DCK2. 

NOTE: Both the infrastructure and the terminal derive DCK during the authentication process. 

The DCK shall be derived from its two parts DCKl and DCK2 by the procedure TB4, as shown in figure 6. In case of 
unilateral authentication, either DCKl or DCK2 shall be set to zero: DCK2 = for an authentication of the MS by the 
infrastructure; DCKl = for an authentication of the infrastructure by the MS. 

If mutual authentication is requested by the MS, but the SwMI does not support mutual authentication and instead 
concludes the authentication, then DCK2 shall be set to "0" when deriving DCK using TB4. 

If mutual authentication is requested by the SwMI, but the MS does not support mutual authentication and instead 
concludes the authentication, then DCKl shall be set to "0" when deriving DCK using TB4. 

If MS initiated authentication is ignored by the SwMI, and instead only SwMI initiated authentication is performed, 
then DCK2 shall be set to "0" when deriving DCK using TB4. 

If SwMI initiated authentication is ignored by the MS, and instead only MS initiated authentication is performed, then 
DCKl shall be set to "0" when deriving DCK using TB4. 

Figure 5: Void 

DCK1 DCK2 

TB4 



DCK 

Figure 6: Derivation of the DCK from its two parts 

In a successful authentication exchange the algorithm TB4 shall always be invoked in accordance with the rules for 
input given above. 

DCK may be used to protect voice, data, and signalling sequences between the infrastructure and an individual MS after 
successful authentication has taken place. 
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4.2.2 The GCK 

GCK applies only to class 3 cells for encryption. 



The GCK shall be known to the infrastructure and distributed to the MSs. GCK shall not be used directly by the air 
interface encryption unit. Within each LA the GCK shall be modified by CCK (see clause 4.2.3) using algorithm TA71 
to provide a Modified GCK (MGCK) for use on the air interface. The process is shown in figure 7. 

If GCK is not defined for a group the value of MGCK shall be equal to that of CCK and algorithm TA71 shall not be 
invoked. 

CCK 




Figure 7: Generation of IVIGCK from GCK and CCK 

One GCK may be associated with more than one group. A GCK Number (GCKN) associated with each GCK can be 
used to identify association with multiple groups. The values of GCKN should be unique between all MSs sharing the 
same sets of GCK. The association of GCK to groups may be changed by the OTAR service to allow automatic key 
management to take place. 

When distributing GCK to an individual by an OTAR mechanism (algorithms TA8 1 and TA82) a session key for 
OTAR (KSO) may be used to protect the GCK, alternatively an EGSKO derived from GSKO may be used. The 
signalling shall indicate the sealing key in use. KSO shall be individual to each MS and shall be derived from an MS's 
authentication key (K) and a random seed RSO with algorithm TA41. 

To allow the GCK to be decrypted by the MS, algorithm TA81 shall have an inverse TA82. To allow the MS to 
discover if GCK has been corrupted due to transmission errors or manipulation, TA81 introduces some redundancy into 
the Sealed Group Cipher Key (SGCK). The algorithm TA81 uses the group key version number (GCK-VN) and the 
Group Cipher Key Number (GCKN), to provide this redundancy. The redundancy is checked by TA82. A detected 
manipulation shall be indicated by setting the manipulation flag MF. The method of determining a valid GCK-VN and, 
therefore, of identifying a replay is outside the scope of the present document. 

When distributing to a group by OTAR an EGSKO derived from GSKO shall be used as the sealing key. 

If MF is TRUE the recovered key shall be discarded. 

The process is summarized in figure 8. 
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Figure 8: Distribution of a group cipher key to an individual IVIS 

4.2.3 The GCK 

CCK applies only to class 3 cells for encryption. 

CCK shall be used to give protection of voice, data, and signalling sequences between the infrastructure and an MS 
when using group addresses (including the broadcast address) on the downlink either as a key modifier of GCK 
(see clause 4.2.2) or as a standalone key. In addition CCK shall be used to generate ESI as described in clause 4.2.6. 

The CCK shall be generated by the infrastructure and distributed to the MSs. There shall be one such key for every 
Location Area (LA): a CCK may be used in more than one LA or there may be a distinct CCK for every LA in the 
system. The MS may request the CCK when registering in an LA as part of the registration protocol, or at any other 
time as part of the CCK delivery protocol. The CCK may then be transmitted in encrypted form using algorithm TA3 1 
and DCK as the sealing key. To allow the CCK to be decrypted by the MS, algorithm TA3 1 shall have an inverse 
TA32. To allow the MS to discover if CCK has been corrupted due to transmission errors or manipulation, TA31 
introduces some redundancy into the Sealed Common Cipher Key (SCCK). The redundancy is checked by TA32. A 
detected manipulation shall be indicated by setting the manipulation flag MF. 

If MF is true the recovered key shall be discarded. 

The infrastructure may change the CCK and distribute the new key to the MSs. For this purpose a CCK Identifier 
(CCK-id) shall be generated and distributed along with the key. CCK-id shall be input to algorithms TA3 1 and TA32 to 
the effect that decryption of the correct CCK shall only be possible if the correct CCK-id has been received. CCK-id 
shall be referenced by one bit in the encryption mode element of the MAC RESOURCE PDU of the encrypted message 
to select the active CCK. The value of this bit shall equal the value of the least significant bit of CCK-id. The method of 
determining a valid CCK-id and, therefore, of identifying a replay is outside the scope of the present document. 

CCK is uniquely identified by the combination of LA-id and CCK-id. Where a CCK applies to many LAs the CCK-id 
shall be the same in each LA. 

The process is summarized in figure 9. 
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Figure 9: Distribution of a common ciphier l<ey 

4.2.4 The SCK 

SCK applies to class 2 cells and to Direct Mode operations (see EN 300 396-6 [5]) for encryption. SCK may also be 
used for encryption in a cell that normally operates in class 3 but is in fallback mode. 

SCK shall be used to protect voice, data, and signalling sequences between the infrastructure and an individual MS in a 
class 2 cell. The SCK may be used to protect voice, data, and signalling sequences between the infrastructure and a 
group-addressed MS. There shall be up to 32 SCKs available to each ITSI. SCK shall be a fixed value that should be 
known to the infrastructure and every MS. The SCKs are termed "static" because they shall not be generated or changed 
by the authentication exchange. 

SCK shall be a member of an SCK set containing up to 32 keys, and each key shall be identified by its position in the 
SCK set (SCK number). Members of an SCK set may be shared amongst TETRA networks and so may be allocated in 
either the home network of the MS or by an external body representing more than one TETRA network. 

SCKs may be protected for distribution using algorithms TA5 1 and TA52, in like manner to the GCK which uses 
algorithms TA81 and TA82. 

An SCK shall be identified by two numbers: 

• The SCK number (SCKN) shall address one of the 32 SCKs stored in an MS; The SCK Version Number 
(SCK-VN) shall identify the version of each of the 32 SCKs and should be incremented for each new key 
identified with the same SCKN. 

• SCK-VN may be used to protect the distribution of the SCKs against replay. The method of determining a 
valid SCK-VN and, therefore, of identifying a replay is outside the scope of the present document. The SCKN 
is input to TA5 1 and output from TA52. 

SCK-VN shall be referenced by one bit in the encryption mode element of the MAC RESOURCE PDU of the 
encrypted message to select the active SCK. The value of this bit shall equal the value of the least significant bit of 
SCK-VN. 

When distributing SCK to an individual by an OTAR mechanism (algorithms TA5 1 and TA52) a session key for OTAR 
(KSO) may be used to protect the SCK, alternatively an EGSKO derived from GSKO may be used. The signalling shall 
indicate the sealing key in use. KSO shall be individual to each MS and shall be derived from an MS's authentication 
key (K) and a random seed RSO with algorithm TA41. 

When distributing to a group by OTAR an EGSKO derived from GSKO shall be used as the sealing key, as described in 
clause 4.2.5. 
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The result of the application of TA51 to SCK, SCK-VN, KSO and SCKN shall be a Sealed Static Cipher Key (SSCK). 
To allow recovery of SCK and SCKN at the MS, SCK-VN and RSO shall be distributed together with SSCK. 

For OTAR, SCKs may be sealed in the same entity that stores the MS's authentication keys, i.e. an authentication 
centre. This case is shown in figure 10. 
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Figure 10: Distribution of SCK to an individual IVIS by an authentication centre 

SCKs may be associated with one or more groups for encryption in DMO (see EN 300 396-6 [5]). The association 
principle is described in clause 4.2.4. 1 . 

SCK may also be deleted from the MS as part of the OTAR procedures. 



4.2.4.1 



SCK association for DMO use 



The OTAR service provided in TMO may also be used to provide key management for DMO. The OTAR service 
allows SCKs to be provided for use in DMO, and for one or more provided SCKs to be associated with one or more 
groups in DMO. The purpose of associating more than one SCK with a DMO group is to allow different SCKs to be 
active at different periods of time in DMO. Associations can be formed for single SCKs or for SCK subsets. 



4.2.4.1.1 



DMO SCK subset grouping 



For each DMO group call where encryption is to be applied, the MS should have a means to associate one or more 
SCKs with the GTSI to be called. The means of associating SCKs with GTSIs may be achieved using air interface 
signalling. 

An SCK should have a defined lifetime or crypto period. At the end of this crypto period, it should be replaced. 
Replacement is achieved when the MS selects a different SCK for transmission. However, as DMO is an uncontrolled 
environment, different MSs may change their SCK selection at different times. To overcome the possibilities for 
communication failure, SCKs may be grouped into one or more subsets to facilitate the key management process. 

Keys in different subsets associated with the same GTSI(s) are referred to by the term Key Association Group (KAG). 
The MS shall consider one SCK of the KAG as current and shall use this SCK as the key for transmission. Any SCK of 
the KAG may be used for reception. 
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EXAMPLE 1 : If SCKN#3, SCKN#1 3, SCKN#23 are members of the same KAG and an MS transmits using 
SCKN#13 then it shall also be prepared to receive using SCKN#3, SCKN#13, SCKN#23. 

The SCKs within the subsets can be activated separately or synchronized and activated together. If an entire subset of 
SCKs is to be activated together, the crypto periods of all SCKs in the subset shall be the same, and the SCK-VNs of all 
SCKs in a subset shall also be the same. 

Subset groups shall be identified by the SCK subset grouping type as shown in table la and the membership of each 
resulting subset shall be identified as shown in table lb. 

The SCK subset numbering shall be determined by the SCK subset grouping type. In all cases, SCK subset grouping 
type = 1 corresponds to the subset with SCKN = 1 as the first value. Other SCK subset grouping types are determined 
according to table lb. 



Table 1a: SCK subset grouping type definitions 



SCK subset 
grouping type 


Maximum number 

of SCK subsets 

(n) 


Maximum number 

of SCKs per subset 

(m) 


Remarks 





1 


30 


Default. 


1 


2 


15 




2 


3 


10 


Suited for past-present-future mode of operation. 


3 


4 


7 


Only 28 keys of 30 are associated to groups. 


4 


5 


6 




5 


6 


5 




6 


7 


4 


Only 28 keys of 30 are associated to groups. 


7 


10 


3 




8 


15 


2 




9 


30 


1 




NOTE: The maximum number of SCKs per subset is limited to 30, as SCKNs 31 and 32 are reserved for TIVIO use. 



Table 1b: Membership by SCKN value of each subset of each SCK subset grouping type 



SCK 

subset 
number 


SCK subset c 


irouping type 


1 


2 


3 


4 


5 


6 


7 


8 


1 


1 to 15 


1 to 10 


1 to 7 


1 to 6 


1 to 5 


1 to 4 


1 to 3 


1 to 2 


2 


16 to 30 


11 to 20 


8 to 14 


7 to 12 


6 to 10 


5 to 8 


4 to 6 


3 to 4 


3 


X 


21 to 30 


15 to 21 


1 3 to 1 8 


11 to 15 


9 to 12 


7 to 9 


5 to 6 


4 


X 


X 


22 to 28 


1 9 to 24 


16 to 20 


1 3 to 1 6 


10to12 


7 to 8 


5 


X 


X 


X 


25 to 30 


21 to 25 


17 to 20 


13to15 


9 to 10 


6 


X 


X 


X 


X 


26 to 30 


21 to 24 


16to18 


11 to 12 


7 


X 


X 


X 


X 


X 


25 to 28 


19 to 21 


13to14 


8 


X 


X 


X 


X 


X 


X 


22 to 24 


15to16 


9 


X 


X 


X 


X 


X 


X 


25 to 27 


17to18 


10 


X 


X 


X 


X 


X 


X 


28 to 30 


19 to 20 


11 


X 


X 


X 


X 


X 


X 


X 


21 to 22 


12 


X 


X 


X 


X 


X 


X 


X 


23 to 24 


13 


X 


X 


X 


X 


X 


X 


X 


25 to 26 


14 


X 


X 


X 


X 


X 


X 


X 


27 to 28 


15 


X 


X 


X 


X 


X 


X 


X 


29 to 30 


NOTE 1 : For SCK subset grouping type = 9 (not shown), 30 subsets of 1 key each, the SCK subset number is equal to 

the SCKN, i.e. SCK subset number = 1 signifies SCKN = 1 and so on. 
NOTE 2: A table entry given by "X" indicates an illegal value that shall not be used. 
NOTE 3: For SCK subset grouping type = (not shown), 1 subset of 30 keys, the SCK subset number is always 1 . 



All SCKNs in a KAG shall be associated with a GTSI by implication when the SCKN in that KAG that is in subset#l is 
associated with that GTSI. 

The association of SCKNs within a KAG with any GTSI can also be determined from the following formula: 

where: 

• SCK(i) are the members of a KAG; 
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• SCK(f) is the associated SCKN in the first subset; and 

• There are (n) subsets, each containing (m) member SCKs. 



Then: 



For j = to (n-1) 
{ 

i = f + m X j 



EXAMPLE 2: Associating GTSI#22 with SCKN#3 in SCK subset grouping type 2 implies association of 
SCKN#3, SCKN#13 and SCKN#23 with GTSI#22, i.e. SCKN#3, SCKN#13, SCKN#23 are 
members of the same KAG. 

EXAMPLE 3: Associating GTSI#22 with SCKN#3 in SCK subset grouping type 4 impUes association of 

SCKN#3, SCKN#9, SCK#15, SCKN#21 and SCKN#27 with GTSI#22, i.e. SCKN#3, SCKN#9, 
SCKN#15, SCKN#21 and SCKN#27 are members of the same KAG. 

EXAMPLE 4: If SCK subset grouping type = 2 (corresponding to 3 subsets of 10 keys), then n = 3, m = 10, and if 
f = 5, then SCKN = 5, SCKN = 15 and SCKN = 25 shall be associated with the same GTSI and are 
members of the same KAG. 

EXAMPLE 5: Figure 10a shows an example of key association for SCK subset grouping type = 2. 



















KAG 1 


KAG 2 


KAG 3 




SCK 
1 subset 1 


.1 r 

SCK1 i 

-' h 




1 ^ 

i SCK 2 1 

1 1 




1 p 

SCK3 i 

1 i. 




Crypto 
period 1 
















SCK 
1 subset 2 


., . 

SCK 11 




I T 

SCK 12 




1 J. 

SCK 13; 




Crypto 
period 2 
































SCK 
1 subset 3 


_i f. 

SCK 21 i 




1 ^ 

SCK 22 i 




1 f. 

SCK 23 i 




Crypto 
period 3 








1 ~ 1 




1 ~ 1 






















GSSI 
1,2,3... 


GSSI 
4,5,6... 


GSSI 
7,8,9... 





Time 



NOTE: GSSI is used in this figure to represent GTSI. 

Figure 10a: Example of key association for SCK subset grouping type = 2 

4.2.5 The GSKO 

In some cases keys may need to be distributed to groups as identified by GTSI. In order to allow the sealing 
mechanisms described in clauses 4.2.2 and 4.2.4 to operate KSO shall be replaced by an Extended Group Session Key 
for OTAR (EGSKO) derived using algorithm TB7 from the Group Session Key for OTAR (GSKO). 
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When distributing GSKO by an OTAR mechanism (algorithms TA91 and TA92) a session key for OTAR (KSO) shall 
be used to protect the GSKO. KSO shall be individual to each MS and shall be derived from an MS's authentication key 
(K) and a random seed RSO with algorithm TA41 as for distribution of SCK and GCK. The GSKO has an associated 
version number, GSKO-VN which can be used for replay protection. 

Algorithm TA91 is used with GSKO, KSO and GSKO-VN as inputs to produce a sealed key SGSKO for transmission 
to an MS. Recovery of GSKO from SGSKO is achieved using algorithm TA92 in conjunction with KSO and GSKO- 
VN as inputs. A manipulation flag MF provides assurance of correct recovery. 

The process is summarized in figure 1 1 . 



MS 



Authentication Centre 



RSO K 

LA 



TA41 



GSKO-VN SGSKO 



LJlI 



KSO 



TA92 



T \ 



MF 



GSKO 



SGSKO, GSKO-VN. 
RSO 



RSO K 



LA 



TA41 



GSKO-VN GSKO 



I u 



KSO 



TA91 



SGSKO 



J 



Figure 1 1 : Distribution of GSKO by an authentication centre 



4.2.5.1 



SCK distribution to groups with OTAR 



When distributing SCK to a group EGSKO shall be used in place of KSO as input to algorithms TA51 and TA52. 
Signalling shall indicate if the distributed SCK is sealed with EGSKO instead of KSO (refer to figure 10). In this case 
the mechanism shall be as shown in figure 10 with TA41 not invoked and KSO replaced by EGSKO. 

EGSKO is derived from GSKO using algorithm TB7 as shown in figure 12. 



GSKO 




EGSKO 

► 



Figure 12: Generation of EGSKO using IB? 



4.2.5.2 



GCK distribution to groups with OTAR 



When distributing GCK to a group, EGSKO shall be used in place of KSO as input to algorithms TA81 and TA82. 
Signalling shall indicate that the distributed GCK is sealed with EGSKO. In this case the mechanism shall be as shown 
in figure 8 with TA41 not invoked and KSO replaced by EGSKO. 



4.2.5.3 



Rules for MS response to group key distribution 



Where a key is provided to the MS using a group addressed transmission, and using the GSKO for key encryption, the 
MS shall determine whether to respond to the group addressed OTAR distribution as follows: 

• if the transmission explicitly requires MSs to respond, each MS shall respond to inform the SwMI of the 

success (or failure) of the transaction following expiry of timer T371 that is set to a random value on receipt of 
the OTAR provision; 
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• if the transmission does not explicitly require MSs to respond, an MS shall respond following the expiry of 
T371 on receipt of the OTAR provision, only if the transmission provides that MS with a key or a version of a 
key that the MS does not have stored; 

• if the transmission does not explicitly require MSs to respond, and the transmission does not provide an MS 
with a key or a version of a key that the MS does not have stored, that MS shall not respond. 

The maximum value to which the timer T371 may be set by the MS is provided by the SwMI. 

If an MS is required to respond for one of the reasons given above, but needs to leave the SwMI by sending ITSI- 
Detach signalling the MS shall consider T371 to have terminated at this point, and should send the response to the 
OTAR signalling before detaching from the SwMI. 

NOTE: If the MS is unable to send the response there is no requirement to store the response. 

4.2.6 Encrypted Short Identity (ESI) mechanism 

The ESI mechanism shall provide a means of protection of identities transmitted over the air interface. It operates in 
addition to, or as a replacement for, the Alias Short Subscriber Identity (ASSI) mechanism described in 
EN 300 392-1 [1], clause 7. 

NOTE 1: In standard TETRA addressing no alias addresses are associated with a group address in the home system. 
The ESI mechanism provides such an alias within a location area for all address types. 

NOTE 2: The broadcast address as defined in EN 300 392-1 [1] is a reserved value of the group address so ESI 
applies to it. 

This clause describes a mechanism that allows the encryption of the SSI segment of addresses used by layer 2. The 
event label and usage marker shall not be encrypted by this mechanism. USSI and SMI shall not be encrypted by this 
mechanism. The mechanism is valid only for networks with air interface encryption applied. The mechanism shall be 
integrated with the use of CCK within a location area in cells of security class 3, or with SCK for cells of security 
class 2. Whenever encrypted signalling is used, the ESI shall be sent instead of the true identity. The mechanism uses 
algorithm TA61 as shown in figure 13. 



CCK or SCK 




Figure 13: Generation of ESI from SSI and a cipher key 

xSSI are all short addresses vaHd for the MS (ISSI, GSSI, ASSI, V-ASSI, V-GSSI). The output xESI (lESI, GESI, 
AESI, V-AESI, V-GESI) shall be a cryptographic address. Only MSs in a location area with the correct values of CCK 
or SCK shall be able to identify messages addressed for their attention. 

If the PDU is encrypted ESI shall be used in that PDU The use of signalling for AI encryption management is more 
fully described in clause 6.5. 

4.2.7 Encryption Cipher Key 

The Encryption Cipher Key (ECK) shall be derived using algorithm TBS from a selected CK. The CK shall be one of 
DCK, CCK, MGCK in class 3 cells, and shall be SCK in class 2 cells. TBS combines CK with CN, CC and LA 
identifier to produce ECK. This is to prevent attacks on the encryption process by replaying cipher text to eliminate the 
keystream, and to prevent keystream replay within the repeat period of the frame numbering system. 
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CK — ► 


165 










CN — ► 






LA-id — ► 




ECK^ 


KSG 




CC — ► 




► 




IV 




^ 






KSS 


Plaintext/Ciphertext ^^ Ciphertext/Plaintext^ 








"W 


w 



Figure 14: Use of TBS to generate ECK 



4.2.8 Summary of Al key management mechanisms 

Table 2 summarizes the pre-conditions and lifetimes for each key. 

Table 2: Cipher Key pre-conditions and lifetime 



Key 


Pre-condition 


Lifetime (see note 6) 


K 


None 


ITS! (see note 1) 


DCK 


Authentication 


Authentication session (see note S) 


CCK 


Authentication 


Not defined (see note 4) 


SCK 


None 


Not defined (see note 2) 


GCK 


None 


Not defined (see note S) 


MGCK 


Authentication 


As per CCK 


GSKO 


None 


Not defined (see note S) 


NOTE 1 
NOTE 2 
NOTES 
NOTE 4 
NOTES 
NOTE 6 


If OTAR is used for SCK, K or GSKO is required. 

K or GSKO is required for OTAR in class 2 and class 3. 

In an MS DCK may be deleted on power down, but shall be retained if encrypted registration is required. 

CCK may be deleted from the MS on power down, but shall be retained if encrypted registration is required. 

Generally long life. 

Refer to clause 5 for considerations of key storage resulting from invocation of the enable-disable protocols. 



Figure 15 shows the fixed relationship between TETRA addresses and cipher keys. The link between each entity 
describes a relationship "is associated with" and the numbers on the link define the form of this relationship. For 
example the ITSI-K relationship shows that for each ITSI there is zero or one K, and for each K there is only one ITSI. 
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CCK 



0,1 



1,n 



LA 



SCK 



0,1 



1,n 



SwM 
I 



SCK 



0,,32 



0,n 



ITSI 1 



0,1 



DCK 



0,1 



^e^ 



0,1 



1,n 



GTSI 



SCK 



0,n 



0,n 



GTSI 



NOTE 1 : 


NOTE 2: 


NOTE 3: 


NOTE 4: 


NOTE 5: 


NOTE 6: 


NOTE 7: 


NOTE 8: 


NOTE 9: 


NOTE 10 


NOTE 1 1 


NOTE 12 


NOTE 13 



An ITSI may have 0, 1 or up to 32 SCKs associated with it. 

An SCK may be associated with 0,1 or many ITSIs (in the diagram "n" represents this). 

An LA may only use one CCK at any one time. 

A CCK may be used in more than one LA (represented by "n"). 

An ITSI may have or 1 key K. 

Key K shall only be associated with 1 ITSI. 

A SwMI shall only use one SCK at any one time except during key changeover periods 

(see also clause 6.5). 

An SCK may be used in more than one SwMI. 

A GCK may be associated with 1 or many GTSIs. 

A GTSI may have or 1 GCK associated with it. 

One or several SCKs may be associated with 0, 1 or many GTSIs for DMO only. 

A GTSI may have or 1 SCK associated with it, or, for DMO only, many SCKs associated with it. 

The diagram does not show transient cases where more than one version of a key may be in use. 

Figure 15: Mapping of Cipher Key and TETRA address relationships 



4.3 Service description and primitives 
4.3.1 Authentication primitives 

At the TNMM Service Access Point (SAP), a specific service shall be provided to allow an application to initiate an 
authentication exchange and to receive its result. The MS-MM shall respond to an authentication demand from the 
SwMI. The primitives required shall be as follows: 

• TNMM-AUTHENTICATE indication shall be used to report to the MS application the result of an 
authentication returned by the SwMI. 

• TNMM-AUTHENTICATE confirm shall be used to confirm successful or failed authentication of the SwMI 
by the MS. 

• TNMM-AUTHENTICATE request shall be used by the MS application to initiate an authentication of the 
SwMI. It may also be used to configure the mutual authentication and registration behaviour of the MS. 

Table 3: TNMM AUTHENTICATE service primitives 



Generic name 


Specific name 


Parameters 


TNMM-AUTHENTICATE 


Indication 


Result, reason 


TNMM-AUTHENTICATE 


Confirm 


Result 


TNMM-AUTHENTICATE 


Request 


Configure 
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The parameters used in the above primitives should be coded as follows: 

• result = 

success; 

failure of MS authentication; 

failure of SwMI authentication; 

• reason = 

authentication pending; 

• configure = 

authenticate SwMI now; 

never mutually authenticate; 

always mutually authenticate; 

never authenticate during location update; 

always authenticate during location update; 

authenticate only in ITSI- Attach form of location update. 

4.3.2 SCK transfer primitives 

A service shall be provided to allow an application to receive new SCKs either on demand or initiated by the SwMI. 
The primitives required shall be as follows: 

• TNMM-SCK indication shall be used to provide the MS application with the SCKN and SCK-VN of each key 
received. 

• TNMM-SCK confirm shall be used by the MS application to confirm that the key information received is 
acceptable, or provide the reject reasons if not. 

• TNMM-SCK request shall be used to request the distribution of a new static cipher key. It shall contain the 
number (of 32 possible values) of each SCK requested. More than one SCK may be requested in one 
transaction. 

Table 4: TNMM SCK service primitives 



Generic name 


Specific name 


Parameters 


TNMM-SCK 


Indication 


SCKN, SCK-VN, GTSI 


TNMM-SCK 


Confirm 


Result 


TNMM-SCK 


Request 


SCKN 



The parameters used in the above primitives should be coded as follows: 

• result = 

SCK received successfully; 

SCK failed to decrypt; 

SwMI Unable to provide SCK; 

• SCKN = 

SCK number 1; 
SCK number 2; 
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SCK number 3; 

SCK number 32; 

• SCK-VN = 

- 0; 

- 216-1. 

4.3.3 GCK transfer primitives 

A service shall be provided to allow an application to receive new GCKs either on demand or initiated by the SwMI. 
The primitives required shall be as follows: 

• TNMM-GCK indication shall be used to provide the MS application with the GCKN, optionally the GTSl, and 
GCK-VN of the key received. 

• TNMM-GCK confirm shall be used by the MS application to confirm that the key information received is 
acceptable, or provide the reject reasons if not. 

• TNMM-GCK request shall be used to request the distribution of a new GCK. It shall contain either the address 
(GTSI) for the GCK requested or the GCKN for the GCK requested. 

Table 5: TNMM GCK service primitives 



Generic name 


Specific name 


Parameters 


TNMM-GCK 


Indication 


GTSI, GCK-VN, GCKN 


TNMM-GCK 


Confirm 


Result 


TNMM-GCK 


Request 


GTSI, GCKN 



The parameters used in the above primitives should be coded as follows: 

• result = 

GCK received successfully; 

GCK failed to decrypt; 

SwMI Unable to provide GCK; 
GTSI = 
1; 
2; 

248-2; 
NOTE: The SSI part of GTSI cannot take the values "OOOOOOig" and "FFFFFFjg". 

• GCK-VN = 
0; 



216-1. 
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• GCKN 

1 

2: 



- 216-1. 

4.3.4 GSKO transfer primitives 

A service shall be provided to allow an application to receive new GSKO either on demand or initiated by the SwMI. 
The primitives required shall be as follows: 

• TNMM-GSKO indication shall be used to provide the MS application with the GSKO-VN of each key 
received. 

• TNMM-GSKO confirm shall be used by the MS application to confirm that the key information received is 
acceptable, or provide the reject reasons if not. 

• TNMM-GSKO request shall be used to request the distribution of a new Group Session Key for OTAR. 

Table 6: TNMM GSKO service primitives 



Generic name 


Specific name 


Parameters 


TNMM-GSKO 


Indication 


GSKO-VN 


TNMM-GSKO 


Confirm 


Result 


TNMM-GSKO 


Request 





The parameters used in the above primitives should be coded as follows: 
result = 

GSKO received successfully; 
GSKO failed to decrypt; 
SwMI Unable to provide GSKO; 
GSKO-VN = 
0; 

216-1. 

4.4 Authentication protocol 
4.4.1 Autinentication state transitions 

Figures 16 and 17 give an overview of the received PDUs that result in a change of authentication state. 
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Process MS Authentication 



"\ r, 



Either Authenticated 
or NotAuthenticated 



D_AUTHENflCATION_DEMAND 
(RS, RAND^) 



Set T354 



TA1 1 , TA21 



Generate 
RAND2 



TA12, TA22 



U_AUTHENTICATION_RESPONSE 
(RES1, RAISie2) 



Pending 



1(2) 



Figure 16: SDL process diagram for SwIUli initiated authentication made mutual by IVIS (page 1 of 2) 
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Process MS Authentication 



2(2) 



Pending 



>T354 



Timer T354 
expires 



D_AUTHENtlCATION_RESULT 

(R1) 



Stop T354 




Return to state 
tliat was in place 
prior to start of the 
authentication process 



No 



Return to state 
that was in place 
prior to start of the 
authentication process 



Yes 




Yes 



R2=FALSE 



R2=TRUE 



U_AUTHEI^ICATION_RESULT 
(R2) / 



EI^JTK 



U_AUTHENTICATION RESULT 

,(R2) 



Authenticated I 






Authenticated = 
Not authenticated ■■ 
Pending = 



The IVIS has performed a successful authentication sequence. 

The MS has not yet been authenticated. 

An authentication sequence has begun and not yet completed. If a new authentication is started 

then any pending authentication shall be abandoned. 



Figure 17: SDL process diagram for SwIVII initiated authentication made mutual by IVIS (page 2 of 2) 
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4.4.2 Authentication protocol sequences and operations 

The air interface authentication protocol shall use the Mobility Management (MM) service of layer 3 in the TETRA 
protocol stack (see EN 300 392-2 [2], clause 14). 

The following statements outline the dynamic requirements described by the protocol: 

• if the authentication procedure fails to complete within time T354 the authenticating parties shall each revert to 
the same authentication state and set of encryption keys that were in place prior to the start of the 
authentication procedure; 

• if DCK is to be used for AI encryption then CCK shall be used to generate ESI and MGCK where used 
(class 3 cell); 

• if authentication is performed during a U-PLANE transmission the DCK change shall take place according to 
the criteria given in clause 4.5.5.1; 

• authentication should be carried out using a previously established encryption key where possible (changeover 
of DCK may be applied at the points shown in the MSCs of this clause); 

• the encryption state (clear or encrypted) shall not be changed during location update signalling. The change 
(if required) shall be made when both the authentication sequence has been completed and the location update 
has been accepted. 

An authentication exchange can be requested, either explicitly or as part of the registration procedure and can be 
initiated by either the MS or SwMI. The initiating side shall send an "AUTHENTICATION DEMAND" PDU that shall 
always be answered by the other side with either an "AUTHENTICATION RESPONSE" or an "AUTHENTICATION 
REJECT" PDU. Success or failure of the authentication shall be communicated by a specific "AUTHENTICATION 
RESULT" PDU. If an MS is not currently involved in an authentication exchange it shall ignore any authentication 
results or rejections addressed to the MS. 

The recipient of the first authentication demand may instigate mutual authentication by use of the mutual authentication 
indicator, and by sending its challenge together with the response to the first challenge. In this case, the response to this 
second challenge shall be sent together with the result of the first challenge. This mechanism saves signalling, as only 
one random seed RS is required, and the functions can be combined in PDUs requiring fewer transmissions at the air 
interface. 

If the mutual authentication flag is set then the recipient knows to use DCKl and DCK2 as input to TB4. If the mutual 
authentication flag is not set then TB4 is run with the "other" DCKx set to zero as stated as clause 4.2.1. Thus, if "MS to 
SwMI" authentication is followed at some later time by "SwMI to MS" authentication, the first exchange will produce a 
DCK with DCK2 set to zero, and the second exchange will produce a DCK with DCKl set to zero. If the mutual 
authentication flag is used and the authentication made mutual, as described above and in clause 4. 1 .4, then DCK is an 
algorithmic combination of DCKl and DCK2. 

After a successful authentication exchange, both MS and SwMI shall replace both parts of the derived cipher key, 
DCKl or DCK2, with the newly calculated values, and the derived cipher key DCK accordingly. 

On sending of an authentication challenge the MS shall start timer T354. On receipt of an authentication challenge the 
MS shall start timer T354. If timer T351 is running it shall be stopped and T354 shall apply. 

When T354 expires the MS and SwMI shall revert to the state that existed prior to the initiating authentication 
challenge. 

NOTE 1 : Repeated expiry of T354 may be used as a reason to select an alternative cell. 

The behaviour described in this clause shall apply whenever authentication takes place, i.e. standalone, at registration, at 
location update. 

If the MS receives a D- AUTHENTICATION RESULT PDU containing a false value of Rl the MS MM may send the 
MS MLE an MLE-UPDATE request primitive with reject cause "LA rejection" so that the MS MLE initiates cell 
reselection as defined in EN 300 392-2 [2], clause 18.3.4.7. If the MS decides to initiate cell selection at this stage, it 
shall treat this as though it received a D-LOCATION UPDATE REJECT PDU with reject cause "Authentication failure 
(system rejection)", and shall count this towards the maximum permitted number of system rejections, as described in 
EN 300 392-2 [2], clause 16.4.1.1. 
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NOTE 2: If the MS does not leave the current cell when it receives a false value of Rl, it may subsequently be 
instructed to leave the cell by receipt of a D-LOCATION UPDATE REJECT PDU. 

If the MS receives an incorrect RES2 value in a D -AUTHENTICATION RESPONSE PDU or a 

D-AUTHENTICATION RESULT PDU, the MS MM service shall send the SwMI a U-AUTHENTICATION RESULT 

PDU with R2 set to false. The MS shall send the MS MLE service an MLE-UPDATE request primitive with 

reject cause "LA rejection" so that the MS MLE initiates cell reselection as defined in EN 300 392-2 [2], 

clause 18.3.4.7. The MS shall treat this as though it received a D-LOCATION UPDATE REJECT PDU with reject 

cause "Authentication failure (system rejection)", and shall count this towards the maximum permitted number of 

system rejections, as described in EN 300 392-2 [2], clause 16.4.1.1. 

If the MS sends the SwMI a U-AUTHENTICATION DEMAND PDU and the MS receives in reply a 
D-AUTHENTICATION REJECT PDU, the MS MM may send the MS MLE an MLE-UPDATE request primitive with 
reject cause "LA rejection" so that the MS MLE initiates cell reselection as defined in EN 300 392-2 [2], 
clause 18.3.4.7. 

If the MS attempts to make an authentication challenge mutual by sending the SWMI a U- 

AUTHENTICATION RESPONSE PDU that includes a RAND2 information element, and if the MS receives in reply a 
D-AUTHENTICATION RESULT PDU that does not contain a RES2 information element the MS MM may send the 
MS MLE an MLE-UPDATE request primitive with reject cause "LA rejection" so that the MS MLE initiates cell 
reselection as defined in EN 300 392-2 [2], clause 18.3.4.7. 



4.4.2.1 



MSCs for authentication 



This clause presents Message Sequence Charts (MSCs) for the authentication protocol to enable the mechanisms 
described in clause 4. 1 . 



Case 


Title 


Figure number 


1 


SwMI authenticates MS 


18 


2 


MS authenticates SwMI 


19 


3 


Authentication initiated by SwMI and made mutual by the MS 


20 


4 


Authentication initiated by MS and made mutual by the SwMI 


21 


5 


SwMI rejects authentication demand from MS 


22 


6 


MS rejects authentication demand from SwMI 


23 



NOTE: In the MSCs where the timer T354 is explicitly shown it is shown as being terminated by the MS-MM 
process and not as having expired. 
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MSC SwMI_to_MS 

Authentication initiated by SwIVll 



Application 



IMS MM 



BS MM 



TNMM /authenticate indication (RES1) 



T354 



D authentication demand 



T354 



{RAND1, RS) 



U AUTHENTICATION RESPONSE 



(Reason) 



D AUTHENTICATION RESULT 



(R1) 



TNMM /authenticate indication 



(Result) 



P 1 



Figure 18: Authentication of lUIS by SwIUII 
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MSC MS to SwMI 



Authentication initiated by IVIS 



Application 



IVIS MIVI 



BS MM 



TNMM_AUTHENTICATE_)-equest 
{ Configure) 

StartT354 



U AUTHENTICATION DEMAND 



{ RAND2) 



D AUTHENTICATION RESPONSE 



(RES2, RS 



StopT354 



U AUTHENTICATION RESULT 



TNMM AUTHENTICATE confirm 



{R2) 



(Result 



Figure 19: Authentication of the SwIVII by the IVIS 
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MSC SwMI_to_MS_Mutual 


Authentication initiated by BS K 
and made mutual by MS 








Application MS_l\/iM 




BSJAM 


TNMI\/1_AL 




D_AUTHENTICATION_DEMAND 










(RAND1,RS ) 




START 
T354 








U_AUTHENTICATION_RESPONSE 




( RES1, RAND2) 

D_AUTHENTICATION__RESULT 








{R1, RES2 ) 




STOP 
T354 








U_AL 


JTHENTICATION_RESULT 


THENTICATEJndication 


(R2) 


(Result ) 





















Figure 20: Authentication initiated by SwIUII and made mutual by the lUIS 
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MSC MS to SwMI Mutual 



Authentication initiated by IVIS ! 
and made mutual by BS 



Application 



MS IVIM 



( Configure) 



TNMI\/l_AUTHENTICATE_'equest 



BS MM 



START 
T354 



{ RAND2) 



U AUTHENTICATION DEMAND 



D AUTHENTICATION RESPONSE 



(RES2, RAND1, RS ) 



U AUTHENTICATION RESULT 



R2, RES1) 



D AUTHENTICATION RESULT 



{R1 ) 



STOP 
T354 



TNMM AUTHENTICATE confirm 



(Result ) 



Figure 21 : Authentication initiated by lUIS and made mutual by the SwIUII 
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MSC MS_to_SwMI_Reject 



Authentication initiated by IVIS 
and rejected by SwIVII 



Application 



IVIS MM 



BS MM 



TNMM_AUTHENTICATE_-equest 



Configure) 



START 
T354 



( RAND2) 



U AUTHENTICATION DEMAND 



STOP 
T354 



TNMM yVUTHENTICATE confirm 



(Result ) 



D AUTHENTICATION REJECT 



(Auth_reject_reason ) 



Figure 22: Authentication initiated by IVIS and rejected by SwMI 
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MSC SwMI_to_MS_Reject 



Authentication initiated by BS 
and rejected by IVIS 



Application 



MS IVIM 



BS MIVI 



T354 



TNIVIIVI AUTHENTICATE indication 



(Result ) 



D AUTHENTICATION DEMAND 



(RAND1, RS ) 



U AUTHENTICATION REJECT 



{ Auth_reject_reason) 



4.4.2.2 



Figure 23: Authentication initiated by SwIVII and rejected by IVIS 



MSCs for authentication Type-3 element 



The type-3 PDU elements Authentication uplink and Authentication downlink contained in the U-LOCATION 
UPDATE DEMAND and D-LOCATION UPDATE ACCEPT PDUs respectively allow authentication and CK key 
exchange to be initiated by the MS. The SwMI then is able to provide the CK for the current LA (of which the serving 
cell is a member) to the registering MS. 

The CK key being requested in the Authentication uplink shall be qualified by the security class field in the ciphering 
parameters, i.e.: 

• if the MS requests the CK in the Authentication uplink, and the ciphering parameters indicate security class 2, 
then the SwMI shall infer that the MS is requesting the SCK in current use; 

• if the MS requests the CK in the Authentication uplink, and the ciphering parameters indicate security class 3, 
then the SwMI shall infer that the MS is requesting the CCK. 
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When the SwMI provides CK information in the Authentication downlink, the SwMI may provide additional CK 
material as well as that requested in the Authentication uplink, i.e.: 

• if the MS requests the CCK in the Authentication uplink, the SwMI may provide the CCK and the SCK in the 
Authentication downlink; 

• if the MS requests the SCK in the Authentication uplink, the SwMI may provide the SCK and the CCK in the 
Authentication downlink. 

The Authentication downlink may also contain a demand for the MS to provide its TEL It is recommended that this 
option is used only if encryption is applied (i.e. in class 2 and class 3 systems). 

This clause shows the message sequence charts for the following cases: 

• MS initiated location update request with embedded CK request and SwMI CK provision (figure 24); 

• MS initiated location update request with embedded Authentication challenge (figure 25); 

• SwMI initiated TEI provision request (figure 26). 



MSC Type3_Auth_UL 

Location update request with embedded L^ 

CCK request. Exchange applies to 
class 2 and 3 systems. Address encryption does 
not apply so initial exchange is without 
encryption applied 



Application 



MS MlVi 



BS MM 



CK not known 



Class 2 3 



AUTHENTICATION UPLINK TYPES 



(CK_request_flag) 



AUTHENTICATION DOWNLINK TYPE3 



( CK_provision_information) 



Figure 24: CK provision during location update 
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MSC Type3_Auth_Loc Update 

Location update request with embedded 
autlientication cliallenge. 



Application 



IMS MM 



BS MM 



T354 



AUTHENTICATION UPLINK TYPES 



(RAND2) 



D AUTHENTICATION RESPONSE 



{RAND1, RS) 



U AUTHENTICATION RESULT 



(RES1) 



AUTHENTICATION DOWNLINK TYPE3 



(R1) 



TNMM AUTHENTICATE 



indication) 



\ 1 



Figure 25: MS initiated authentication during location update 
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MSC TELProvide 

TEI Provided preferably 

only in class 2 or class 3 system 



Application 



MS MM 



BS MM 



If authentication 
has not been 
performed R1 
is ignored 



D-LOCATION UPDATE ACCEPT 



^^ , TEI_request_flag ) 



U TEI PROVIDE 




LOCATION UPDATE Successful 



NOTE: If D-LOCATION UPDATE ACCEPT is received R1 may be ignored. 

Figure 26: TEI Provision in class 2 or 3 system 

4.4.2.3 Control of authentication timer T354 at MS 

The timer shall be started under the following conditions: 

• on sending of U- AUTHENTICATION DEMAND; 

• on receipt of D-AUTHENTICATION DEMAND; and 

• on sending of U-LOCATION UPDATE DEMAND containing an Authentication challenge in the type-3 
element "Authentication uplink". In this case the value of T354 shall be the same as T351 and only one of 
these timers needs to be started. 
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The timer shall be stopped (cancelled) under the following conditions: 

• on receipt of D- AUTHENTICATION RESULT for SwMI initiated unilateral authentication, and for 
authentication initiated by the MS but made mutual by the SwMI; 

• on sending of U- AUTHENTICATION RESULT for MS initiated unilateral authentication, and for 
authentication initiated by the SwMI but made mutual by the MS; 

• on sending of U- AUTHENTICATION REJECT; 

• on receipt of D-AUTHENTICATION REJECT; 

• on receipt of D-LOCATION UPDATE REJECT; and 

• on receipt of D-LOCATION UPDATE ACCEPT containing the type-3 element "Authentication downlink". 
NOTE: The behaviour of T354 in the SwMI has to be set to ensure correct MS operation. 

4.5 OTAR protocols 

4.5.1 CCK delivery - protocol functions 

CCK is a cipher key linked to the use of Air Interface encryption with DCK. This clause describes the key management 
protocols used to support the algorithms and mechanisms described in clause 4.2.3. CCK is required prior to enabling 
encrypted air interface services on a cell as it is linked to the ESI mechanism used for layer 2 addressing 
(see clause 4.2.6). 

CCK shall be delivered over the air interface using the mechanisms and protocols described in this clause, and by the 
registration and authentication procedures defined in clause 4.4.2. 

When scanning a cell prior to registration an MS shall receive the CCK-id and LA-id of the CCK in use on that cell in 
the S YSINFO broadcast. If the CCK so identified is not known to the MS it shall request the CCK either through its 
current serving cell or at the new cell using the protocols defined in the present document. 

The SwMI can deliver to all registered MSs a CCK for future use. 

When delivering a CCK the SwMI shall indicate the LAs for which the CCK is valid. This may be in the form of a list 
of LAs, a bit mask of LA identities, a range of LA identities, or it may be applied to all LAs. When sending CCK by a 
list the list shall include the corresponding LA identity. 

The LA selector and mask mechanism is intended to find if the CCK applies to the current LA. To achieve this the mask 
is logically ANDed with the LA-id received from the SwMI in the broadcast parameters. If the result is equal to the 
selector, then CCK is valid for the current LA-id. 

The CCK may be provided explicitly by the SwMI using the "D-OTAR CCK Provide" PDU, the "D-OTAR 
NEWCELL" PDU, or may be provided during the registration procedure using the MM type 3 element "Authentication 
downlink" contained in "D-LOCATION UPDATE ACCEPT PDU". 

An MS may explicitly request a CCK from the SwMI using the "U-OTAR CCK Demand" PDU, or the "U- 
OTAR PREPARE PDU", or CCK may be requested during the registration procedure using the MM type 3 element 
"Authentication uplink" contained in "U-LOCATION UPDATE DEMAND" PDU. 

When an MS is authenticated and requests CCK within the location update sequence, then the DCK that is generated in 
the authentication exchange shall be used to seal the provided CCK(s). 

4.5.1 .1 SwMI-initiated CCK provision 

The scenario in figure 27 shows how the SwMI can distribute new CCK information. The SwMI can initiate CCK 
provision at any time when the MS is registered on the cell. The SwMI may provide the CCK of the current cell or the 
CCK of any other cell. The LAs for which the CCK is valid are always identified in the D-OTAR CCK Provide PDU in 
the CCK information element. 

The normal message sequence in this case shall be according to figure 27. 
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MSC OTAR_CCK_SwMI Init 

OTAR of CCK initiated by SwIVII 



UL 



IMS MIM 



BS MM 



ClassS 



Autlienticated 



DCKIn use 



TA31 



D OTAR CCK PROVIDE 



CCK ID,SCCK, LA Information) 



TA32 



U OTAR CCK RESULT 



(Provision_Result) 



Figure 27: SwMI Initiated CCK provision 

4.5.1 .2 MS-initiated CCK provision with U-OTAR CCK demand 

The normal message sequence in this case shall be according to figure 28. 
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MSC OTAR_CCK_MS. I nit 

OTAR of CCK initiated by IVIS 



UL 



IMS MIM 



BS MM 



ClassS 



Autlienticated 



DCKIn use 



U OTAR CCK DEMAND 



(LA) 



TA31 



D OTAR CCK PROVIDE 



CCK ID,SCCK, LA Information) 



TA32 



U OTAR CCK RESULT 



(ProvisionResult) 



4.5.1.3 



Figure 28: MS-initiated CCK provision 



MS-initiated CCK provision with announced cell reselection 



Whilst the primary use of the U-PREPARE PDU is to allow call restoration when moving between cells it may also be 
used by an MS to request the CCK for the new cell, or to forward register to a new cell using the announced type 1 cell 
re-selection mechanism. In order to support encrypted cell change to class 3 cells the U-PREPARE PDU may carry an 
U-OTAR CCK Demand PDU. 
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For announced type 1 cell reselection where the CCK of the new cell is required two options exist: 

1) MS required to register: 

the CK request for CCK information shall be sent in the U-LOCATION UPDATE DEMAND PDU 
carried by the U-PREPARE PDU; 

2) MS not required to register: 

the CCK request shall be sent in the U-OTAR CCK Demand PDU carried by the U-PREPARE PDU. 

Case 1 : New cell is in same LA and same registered area 

MS shall assume that the current values of CCK and DCK will be valid on new cell. U-PREPARE shall contain no MM 
PDUs. 

Case 2: New cell is in different LA but same registered area 

Before roaming to a new cell the MS may request the CCK of the new cell from its current serving cell by sending U- 
OTAR CCK Demand with LA = LA of new cell. The U-OTAR CCK Demand PDU may be sent in the U-PREPARE 
PDU, in case MS is allowed to make the announced cell re-selection. The MS shall assume that DCK is valid in the new 
cell. 

The SwMI shall supply the CCK of the requested LA using the D-OTAR CCK Provide PDU, which may be contained 
in the D-NEW CELL PDU, or it may inform the MS that provision is not possible. 

Case 3: New cell is in different LA and different registered area 

For roaming to a cell of class 3 only using announced type 1 cell reselection, the MS shall send U-PREPARE with U- 
LOCATION UPDATE DEMAND and CK request for CCK information (if needed). If the new cell accepts the 
registration the SwMI shall ensure that the new serving cell, and the LA to which it belongs, has DCK of the roaming 
ITSI. The acceptance of the registration shall be contained in D-NEW-CELL containing D- 
LOCATION UPDATE ACCEPT and the CCK information of the new cell if requested. 

For roaming to cells of class 3 only using announced type 2 cell reselection, the MS may send U-PREPARE with a 
CCK request (using U-OTAR CCK demand). If the new cell accepts the cell reselection the MS shall assume that the 
new serving cell, and the LA to which it belongs, has DCK of the roaming ITSI. The acceptance of the cell reselection 
shall be contained in D-NEW-CELL which, if requested, may contain the CCK information of the new cell (using D- 
OTAR CCK Provide). 

See also clause 6.6 for change of class on moving between cells. 

4.5.2 OTAR protocol functions - SCK 

Up to seven SCKs may be distributed to the MS using the "D-OTAR SCK Provide" PDU. The provision may be started 
automatically by the SwMI or in response to a request from the MS using the "U-OTAR SCK Demand" PDU. The 
'SCK Use' element contained in each 'SCK Key and Identifier' element within the PDU shall be used by the MS to 
determine whether a particular SCK is to be used in TMO or in DMO. The received value for the 'SCK Use' element for 
a provided SCK shall overwrite any previous value held by the MS for that SCK. The most common cases are described 
by the MSCs and protocol description in the following clauses. 

The MS shall send U-OTAR SCK RESULT according to the rules below. 

• For MS requests and where the SwMI provides keys individually addressed to the MS a result shall always be 
sent (figure 29). When the SwMI responds individually addressed to the MS, the SwMI shall set 
Acknowledgement Flag to "Acknowledgement required" and Explicit Response to "Response to be sent 
whether state changed or not". However, the SwMI may provide keys addressed to a CMG GTSI, in response 
to an MS's individual request, in which case the MS shall interrogate the value of the Acknowledgement Flag 
to determine if an acknowledgement is required. If an acknowledgement is required the MS shall also 
interrogate the Explicit Response element in D-OTAR SCK PROVIDE. If set to "Response to be sent whether 
state changed or not" the MS shall respond whether the key provide changes the MS state or not; if set to 
"Response to be sent only if state of MS is changed", the MS shall only respond if the SwMI provides a key or 
key version that the MS did not previously have. 
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• For SwMI provision to a single MS a response shall always be sent (figure 30). The SwMI shall set 
Acknowledgement Flag to "Acknowledgement required" and Explicit Response to "Response to be sent 
whether state changed or not" when sending D-OTAR SCK Provide to a single MS. 

• For SwMI provision to CMG GTSI (figure 31) the MS shall interrogate the value of the Acknowledgement 
Flag to determine if an acknowledgement is required. If an acknowledgement is required the MS shall also 
interrogate the Explicit Response element in D-OTAR SCK PROVIDE. If set to "Response to be sent whether 
state changed or not" the MS shall respond whether the key provide changes the MS state or not; if set to 
"Response to be sent only if state of MS is changed", the MS shall only respond if the SwMI provides a key or 
key version that the MS did not previously have. 

4.5.2.1 MS requests provision of SCK(s) 

The scenario in figure 29 shows the case where the MS requests provision of one or more SCKs in use on a system. The 
normal message sequence in this case shall be according to figure 29 that shows the invocation of algorithms at each of 
MS and BS to satisfy the request. 

NOTE: Figure 29 shows individual encryption of SCK using KSO, however use of GSKO as shown in figure 3 1 
is also possible for an individually or group addressed OTAR transmission. 

The SwMI shall respond with the requested keys using the D-OTAR SCK Provide PDU, together with the SCKN and 
SCK-VN information. The MS shall respond and inform the SwMI of the success or failure of the OTAR using the U- 
OTAR SCK Result PDU I accordance with the rules mentioned in clause 4.5.2. In case of failure, it shall indicate the 
reason, which may include failure to decrypt the key, or SwMI provided the wrong key. 

For individual provision of SCKs to an MS, the "max response timer value" element in the provision PDU shall be set 
to "0". 
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MSCOTAR SCK MS Init 



OTAR of SCK initiated by IVIS 



Application 



BS MIVI 



( SCKN) 



TNMM_SCK_Request 




(RSO, SCK-VN, SSCK(^) 



TA41 



TA52 



U OTAR SCK RESULT 



SCK_Number_and_Result) 



TNMIVl SCK confirm 



(Result ) 



4.5.2.2 



Figure 29: SCK delivery initiated by lUIS to an individual 



SwMI provides SCK(s) to individual MS 



The scenario in figure 30 shows the case where the SwMI provides one or more SCK(s) to an MS without the MS first 
requesting SCK provision. The SwMI may initiate this procedure at any time. 

The normal message sequence in this case shall be according to figure 30. 

NOTE: Figure 30 shows individual encryption of SCK using KSO, however use of GSKO as shown in figure 3 1 
is also possible for an individually or group addressed OTAR transmission. 
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For individual provision of SCKs to an MS, the "max response timer value" element in the provision PDU shall be set 
to "0". 

The MS shall respond and inform the SwMI of the success or failure of the OTAR using the U-OTAR SCK result PDU. 
The options are as detailed in clause 4.5.2.1. 



MSC OTAR SCK SwMI Init 



OTAR of SCK to an individual 
initiated by SwiVII 



Application 



IVIS MM 



TA41 



TA52 



BS MM 



TA41 



TA51 



D OTAR SCK PROVIDE 



(RSO, SCK-VN, SSCK 



U OTAR SCK RESULT 



SCK_Number_and_Result) 



TNMM_SCK_indication 
PCKN, SCK_VN ) 



Figure 30: SCK delivery to an individual initiated by SwMI 
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4.5.2.3 SwMI provides SCK(s) to group of MSs 

In the case of group addressed delivery of SCK, BS_MM and MS_MM shall not run TA41, but shall use EGSKO as 
input to TA51 and TA52. The U-OTAR SCK RESULT shall be sent from MS to SwMI following the expiry of random 
timer T371 provided that the Acknowledgement Flag is set to "Acknowledgement required" and either the SCK 
material provided is not currently stored in the MS, or the "explicit response" element of the D-OTAR SCK PROVIDE 
PDU is set to "Response to be sent whether state changed or not". T371 is started on reception of the D-OTAR SCK 
PROVIDE. 

T371 is a timer with a value randomized to fall within the range 1 s and a maximum value that is signalled by the SwMI 
in the "max response timer value" element of the PDU. This maximum value may be up to 65 535 s (18,2 hours). The 
MS shall select a value in this range when setting T371. When T371 expires the MS shall wait a further random number 
of random access signalling slots before sending the U-OTAR SCK RESULT PDU. The procedure for randomly 
selecting the signalling slot shall follow the procedure for "Choosing from a new access frame" as defined in 
EN 300 392-2 [2], clause 23.5.1.4.6. If the MS needs to leave the SwMI by sending ITSI-Detach signalling the MS shall 
consider T371 to have terminated and shall send the U-OTAR SCK RESULT PDU before detaching from the SwMI. 

The scenario in figure 31 shows the case where the SwMI provides one or more SCK(s) to a group of MSs identified by 
GTSI. The SwMI may initiate this procedure at any time. 

The normal message sequence in this case shall be according to figure 31. 
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MSC OTAR_SCK_SwMI_2_Group 



OTARof SCKto a group 
initiated by SwMI 



Application 



IMS MM 



TA52 



TNMM SCK indication 



(SCKN, SCK_VN,GTSI) 



^ 



T371 



BS 



TA51 



D OTAR SCK PROVIDE 



GSKO-VN, SCK-VN, SSCK, KSGN) 



T371 expires 



Sent a random 
number of 
random access 
slots after T371 
expires 



U jGTAR SCK RESULT 



(SCK_Number_and_Result ; 



NOTE: Although SCK is sealed by the group key the D-OTAR SCK PROVIDE may be distributed to either a group 
or an individual address and encrypted appropriately. 

Figure 31 : SCK delivery to a group initiated by SwIVIi 
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4.5.2.4 SwMI rejects provision of SCK 

If the SwMI is unable to provide an SCK the provision request shall be explicitly rejected using the D-OTAR SCK 
reject PDU indicating the reason for rejection. 

4.5.3 OTAR protocol functions - GCK 

Up to seven GCKs may be distributed to the MS using the "D-OTAR GCK Provide" PDU. The provision may be 
started automatically by the SwMI or in response to a request from the MS using the "U-OTAR GCK Demand" PDU. 
The most common cases are described by the MSCs and protocol description in the present clause. 

The MS shall send U-OTAR GCK RESULT according to the rules below. 

• For MS requests, and where the SwMI provides keys individually addressed to the MS, a result shall be sent 
(figure 32). When the SwMI responds individually addressed to the MS, the SwMI shall set Acknowledgement 
Flag to "Acknowledgement required" and Explicit Response to "Response to be sent whether state changed or 
not". However, the SwMI may provide keys addressed to a CMG GTSI, in response to an MS's individual 
request, in which case the MS shall interrogate the value of the Acknowledgement Flag to determine if an 
acknowledgement is required. If an acknowledgement is required the MS shall also interrogate the Explicit 
Response element in D-OTAR GCK PROVIDE. If set to "Response to be sent whether state changed or not" 
the MS shall respond whether the key provide changes the MS state or not; if set to "Response to be sent only 
if state of MS is changed", the MS shall only respond if the SwMI provides a key or key version that the MS 
did not previously have. 

• For SwMI provision to a single MS a response shall always be sent (figure 33). The SwMI shall set 
Acknowledgement Flag to "Acknowledgement required" and Explicit Response to "Response to be sent 
whether state changed or not" when sending D-OTAR GCK Provide to a single MS. 

• For SwMI provision to a CMG GTSI the MS shall interrogate the value of the Acknowledgement Flag to 
determine if an acknowledgement is required. If an acknowledgement is required the MS shall also interrogate 
the Explicit Response element in D-OTAR GCK PROVIDE. If set to "Response to be sent whether state 
changed or not" the MS shall respond whether the key provide changes the MS state or not; if set to "Response 
to be sent only if state of MS is changed", the MS shall only respond if the SwMI provides a key or key 
version that the MS did not previously have. 

4.5.3.1 MS requests provision of GCK 

The scenario in figure 32 shows the case where the MS requests provision of a GCK for a group. The MS may initiate 
this procedure at any time. 

The MS may request GCKs associated with one or more GSSIs in which case it shall send a U-OTAR GCK Demand 
PDU to the SwMI indicating that it is requesting GCKs referenced by one or more GSSIs and shall include the GSSIs or 
GTSIs of the requested group(s). Alternatively, the MS may request a new version of one or more GCKs that it already 
possesses. In this case, it shall send a U-OTAR GCK Demand PDU to the SwMI indicating that it is requesting one or 
more GCKs referenced by GCKNs, and shall include the GCKNs of the requested key(s). The MS may request GCKs 
referenced by GSSIs and GCKs referenced by GCKNs in the same PDU; however the total number of requests shall not 
exceed seven in a single U-OTAR GCK Demand PDU. 

All GCKs requested in a single PDU shall belong to the same network, either the serving network in which case the 
"address extension" element shall not be provided, or any other network in which case the "address extension" element 
shall be provided and shall identify the network in which the GCKs are to be used. 

The normal message sequence in this case shall be according to figure 32. 

NOTE: Figure 32 shows individual encryption of GCK using KSO, however use of GSKO as shown in figure 34 
is also possible for an individually or group addressed OTAR transmission. 

For individual provision of GCKs to an MS using KSO as the sealing key, the "max response timer value" element in 
the provision PDU shall be set to indicate "Immediate response". 
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The SwMI shall respond with the requested keys using the D-OTAR GCK Provide PDU, together with the GCKN and 
GCK- VN information. The MS shall respond and inform the SwMI of the success or failure of the OTAR using the D- 
OTAR GCK Result PDU in accordance with the rules in clause 4.5.3. In case of failure, it shall indicate the reason, 
which may include failure to decrypt key, or SwMI provided the wrong key. 

If the KSG identified in the U-OTAR GCK DEMAND is invalid the SwMI shall respond with error indication "KSG 
number not supported". 

If the KSG identified in the D-OTAR GCK PROVIDE is invalid the MS shall respond with error indication "KSG 
number not supported". 
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MSC OTAR GCK MS Init 



OTAR of GCK initiated by IVIS 



Application 



IVIS MIVI 



ALT) 




TNMIVI_GCK_Request 



U OTAR GCK DEIVIAND 



(GCKN) 



U OTAR GCK DEIVIAND 



(GTSI) 



BS IVIIVI 



TA41 



TA81 



D OTAR GCK PROVIDE 



{ RSO, GCK-VN, GCKN, SGCK) 




TNMM GCK confirm 



(Result) 



U OTAR GCK RESULT 



(GCKN, GCK-VN, Provision_Result 



Figure 32: GCK delivery initiated by IVIS to an individual 
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4.5.3.2 SwMI provides GCK to an individual MS 

The scenario in figure 33 shows the case where the SwMI provides a GCK to an MS without the MS first requesting 
GCK provision. The SwMI may initiate this procedure at any time. The SwMI shall provide the GCK to the MS using 
the D-OTAR GCK Provide PDU. The SwMI may provide one or more GCKs, each associated with a specific GSSI, in 
which case the Group Association element in the PDU shall indicate "GSSI" and the SwMI shall provide the GSSI. 
Alternatively, the GCK(s) may be either newer versions of a GCK that the MS already possesses, or new GCK(s) which 
will subsequently be associated with one or more Gossips. In this alternative case the Group Association element in the 
PDU shall indicate "GCKN" and the SwMI shall provide the GCKN relevant to the GCK. 

The normal message sequence in this case shall be according to figure 33. 

NOTE: Figure 33 shows individual encryption of GCK using KSO, however use of GSKO as shown in figure 34 
is also possible for an individually or group addressed OTAR transmission. 

For individual provision of GCKs to an MS using KSO as the sealing key, the "max response timer value" element in 
the provision PDU shall be set to indicate "Immediate response". The MS shall respond and inform the SwMI of the 
success or failure of the OTAR using the U-OTAR GCK Result PDU. The options are as detailed in clause 4.5.3.1. 



£75/ 



60 



ETSI TS 100 392-7 V2.4.1 (2006-10) 



MSC OTAR GCK SwMI Init 



OTAR of GCK initiated by 
SwIVII 



Application 



I VIS I VI 



TA41 



TA82 



TNMM GCK indication 



(GTSI, GCKN) 



-BS- 



TA41 



TA81 



D OTAR GCK PROVIDE 



( RSO, GCKN, GCK-VN, SGCK) 



U OTAR GCK RESULT 



(GCKN, GCK-VN, Provision_Result ] 



Figure 33: GCK delivery initiated by SwIUli to an individual 
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4.5.3.3 SwMI provides GCK to a group of MSs 

In the case of group sealed delivery of GCK, BS_MM and MS_MM shall not run TA41, but shall use EGSKO as input 
to TA81 and TA82. The U-OTAR GCK RESULT shall be sent from MS to SwMI following the expiry of random timer 
T371 provided that the Acknowledgement Flag is set to "Acknowledgement required" and either the GCK material 
provided is not currently stored in the MS, or the "explicit response" element of the D-OTAR GCK PROVIDE PDU is 
set to "Response to be sent whether state changed or not ". T371 is started on reception of the D-OTAR GCK 
PROVIDE. 

T371 is a timer with a value randomized to fall within the range 1 s and a maximum value that is signalled by the SwMI 
in the "max response timer value" element of the PDU. This maximum value may be up to 65 535 s (18,2 hours). The 
MS shall select a value in this range when setting T371. When T371 expires the MS shall wait a further random number 
of random access signalling slots before sending the U-OTAR GCK RESULT PDU. The procedure for randomly 
selecting the signalling slot shall follow the procedure for "Choosing from a new access frame" as defined in 
EN 300 392-2 [2], clause 23.5.1.4.6. If the MS needs to leave the SwMI by sending ITSI-Detach signalling the MS shall 
consider T371 to have terminated and shall send the U-OTAR GCK RESULT PDU before detaching from the SwMI. 

The normal message sequence in this case shall be according to figure 34. 
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MSC OTAR_GCK_SwMI_2_Group 



OTARof GCKtoagroup 
initiated by SwMI 



Application 



IMS MM 



TA82 



TNMM_GCKJndication 

(GTSI, GCKN) 
T371 



BS MM 



TA81 



D OTAR GCK PROVIDE 



{ GSKO-VN,GCKN,GGK-VN, SGGK) 



T371 expires 



Sent a random number 
of time slots after T371 
expires 



U_OTAR_GCK_RESULT 



(GCKN, GCK-VN, Provision_Result 



NOTE: Although GCK is sealed by the group key the D-OTAR GCK PROVIDE may be distributed to either a 
group or an individual address and encrypted appropriately. 

Figure 34: GCK delivery to a group initiated by SwIVII 



4.5.3.4 



SwMI rejects provision of GCK 



If the SwMI is unable to provide a GCK the provision request shall be explicitly rejected using the D-OTAR GCK 
Reject PDU indicating the reason for rejection. 
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4.5.4 Cipher key association to group address 

When provisioning a GSSI into an MS's group database using SS-DGNA, the SwMI may provide a GCK Association 
and/or SCK Association by including the Security Related Information element in D-FACILITY (ASSIGN) PDU, 
see table 6.1. 

Table 6.1 : Security Related Information Element 



Information element 


Length 


Type 


C/O/IM 


Value 


Remark 


GCK Association 


1 




M 


02 
12 


GCK association information not 

provided 

GCK association information provided 


GCK Select Number 


17 




C 




Provided if GCK Association indicates 
"GCK Association Information 
Provided"; IE defined in the present 
document 


SCK Association 


1 




M 


02 
12 


SCK association information not 

provided 

SCK association information provided 


SCK Subset Grouping Type 


4 




C 




Provided if SCK Association indicates 
"SCK Association Information 
Provided"; IE defined in the present 
document 


SCK Subset Number 


5 




C 




Provided if SCK Association indicates 
"SCK Association Information 
Provided"; IE defined in the present 
document 



When performing group attachment, the SwMI may provide a GCK Association and/or SCK Association by including a 
new Group Identity Security Related Information element (see table 6.2) in D-ATTACH/DETACH GROUP 
IDENTITY, D-ATTACH/DETACH GROUP IDENTITY ACK and D-LOCATION UPDATE ACCEPT. 

Table 6.2: Group Identity Security Related Information Element 



Information element 


Length 


Type 


C/O/M 


Value 


Remark 


Number of groups 


5 




M 




Indicates the number of GSSI 
corresponding to the given key 
association that follows 


GSSI 


24 




CM 




Shall be present as many times as 
indicated in the "Number of groups" 
value 


GCK Association 


1 




M 


02 
12 


GCK association information not 

provided 

GCK association information provided 


GCK Select Number 


17 




C 




Provided if GCK Association indicates 
"GCK Association Information 
Provided"; IE defined in the present 
document 


SCK Association 


1 




M 


02 
12 


SCK association information not 

provided 

SCK association information provided 


SCK Subset Grouping Type 


4 




C 




Provided if SCK Association indicates 
"SCK Association Information 
Provided"; IE defined in the present 
document 


SCK Subset Number 


5 




C 




Provided if SCK Association indicates 
"SCK Association Information 
Provided"; IE defined in the present 
document 
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4.5.4.1 SCK association for DMO 

The OTAR KEY ASSOCIATE protocol exchange allows the SwMI to make links between keys and group addresses. 

The SwMI may request that the MS associates a particular SCK (identified by SCKN) with up to 30 groups (identified 
by the "Number of groups" element of the PDU) for which the GSSI of each is listed, or for a range of groups identified 
by the first and last GSSIs in the range. In this case the key-type element of the D-OTAR KEY ASSOCIATE 
DEMAND shall be set to SCK. 

The SwMI may request that the MS associates more than one SCK to one or more groups, where the SCKs are 
members of the same KAG in different SCK subsets. In this case, it will also identify the structure of the subsets and the 
member SCK to be associated. This is described in clause 4.5.4.2. 

A later association shall take precedence over an earlier association. This allows the SwMI to make associations to 
ranges and sub-ranges of groups. The SwMI may associate one key with a wide range of groups, then make an 
association of a second key with a narrower range within the first range. In this case, the first association still applies 
over the wide range with the exception of the narrow range, where the second later association shall apply. 

The SwMI may also demand that groups be associated to SCKs by groups of MSs. In this case, the D-OTAR KEY 
ASSOCIATE DEMAND PDU is addressed to the group of MSs. If the Acknowledgement Flag element is set to 
indicate acknowledgement required the MS shall respond on expiry of random timer T371 provided that the 
Acknowledgement Flag is set to "Acknowledgement required" and either the key association is new to the MS, or 
provided that the "explicit response" element of the D-OTAR KEY ASSOCIATE DEMAND PDU is set to "Response 
to be sent whether state changed or not" (i.e. Response to be sent whether state changed or not). If so the MS shall start 
random timer T371 on reception of D-OTAR KEY ASSOCIATE DEMAND and send the U-OTAR KEY ASSOCIATE 
STATUS on expiry of T371. If the "explicit response" element is set to "0" (i.e. Response to be sent only if the state has 
changed), and the D-OTAR KEY ASSOCIATE DEMAND PDU does not change the MS's state (it already has the key 
association being signalled) it shall not send acknowledgement. If the MS needs to detach from the SwMI before 
sending the acknowledgement to the SwMI, it shall consider T371 to have expired and shall send the acknowledgement 
before detaching. T371 is described in clause 4.5.2.3. If the MS is unable to send the result PDU before detaching, it 
should store the PDU and send it next time it attaches to the SwMI, even if is switched off and on again in the 
meantime. 

The value of T371 shall be provided to the MS by the SwMI in the "max response timer value" element. If the PDU is 
individually addressed to a single MS, this element shall be set to "0". 

The normal message sequence in this case shall be according to figure 35. 
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MSC SCK_Assoc_GTSI 

Command to associate an SCK with 
one or more group addresses 



Application 



IMS MM 



BS MM 



D OTAR KEY ASSOCIATE DEMAND 



SCK select number, SCK subset grouping, GSSI) 



OPT 



T371 



U OTAR KEY ASSOCIATE STATUS 



(SCK subset grouping, Key association status ) 



NOTE: The optional sequence is employed if the rules for sending U-OTAR KEY ASSOCIATE STATUS defined in 
clause 4.5.4.1 are enabled. 

Figure 35: SCK association by SwIUII 

The SwMI may demand that the SCKs currently associated with the groups are disassociated forcing the groups to 
revert to clear operation. This is done by setting the "SCK select number" element to the value for "No SCKN selected". 
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The normal message sequence in this case shall be according to figure 36. 



MSC SCK_DisAssoc_GTSI 

Command to disassociate an SCK 
from one or more group addresses 



Application 



IVIS MIVI 



BS MM 



D OTAR KEY ASSOCIATE DEMAND 



{ No SCKN selected, SCK subset grouping, GSSI) 



OPT 



T371 



U OTAR KEY ASSOCIATE STATUS 



(SCK subset grouping. Key association status ) 



NOTE: The optional sequence is employed if the rules for sending U-OTAR KEY ASSOCIATE STATUS defined in 
clause 4.5.4.1 are enabled. 

Figure 36: SCK disassociation by SwMI 

If in either case, the SwMI requests the MS to associate keys with GSSIs that the MS does not possess, the MS can 
reject the association and indicate the status of this back to the SwMI. If the SwMI requests the MS to associate keys 
with a range of GSSIs, and the MS does not have GSSIs either at the end points of the range, or elsewhere in the range, 
it should still accept and maintain this association in case groups are subsequently loaded within this range. 
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MSC DisAssoc_Exceptional 

Rejected command to disassociate 

an SCK from one or more group addresses 



Application 



IMS MM 



BS MM 



D OTAR KEY ASSOCIATE DEMAND 



SCK select number, SCK subset grouping, GSSI) 



OPT 



T371 



U OTAR KEY ASSOCIATE STATUS 



(SCK subset grouping. Association rejected ) 



ZJ 



NOTE: The optional sequence is employed if the rules for sending U-OTAR KEY ASSOCIATE STATUS defined in 
clause 4.5.4.1 are enabled. 

Figure 36a: Rejection of SCK disassociation 



4.5.4.2 



GCK association 



The scenario in figure 37 shows the case where the SwMI requests the MS to associate a GCK (which the MS already 
has) with between 1 and 30 groups or a range of groups where the ends of the range are identified by a lower and higher 
value of GSSI. 

The SwMI may also demand that groups may be associated to GCKs by groups of MSs. In this case, the D-OTAR KEY 
ASSOCIATE DEMAND PDU is addressed to the group of MSs. If the Acknowledgement Flag element is set to 
indicate acknowledgement required, the MS shall start random timer T371 on reception of D-OTAR KEY 
ASSOCIATE DEMAND and send the U-OTAR KEY ASSOCIATE STATUS on expiry of T371. T371 is described in 
clause 4.5.2.3. 
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The value of T371 shall be provided to the MS by the SwMI in the "max response timer value" element. If the PDU is 
individually addressed to a single MS, this element shall be set to "0". 

The normal message sequence in this case shall be according to figure 37. 



MSC GCK_Assoc_GTSI 

Command to associate an GCK with 
one or more group addresses 



UL 



IVIS MIVI 



BS MM 



D OTAR KEY ASSOCIATE DEMAND 



{ GCK-Select-Number, GSSI) 



OPT 



T371 



U OTAR KEY ASSOCIATE STATUS 



(Key assocation status) 



NOTE: The optional sequence is employed if the rules for sending U-OTAR KEY ASSOCIATE STATUS defined in 
clause 4.5.4.2 are enabled. 

Figure 37: GCK association by SwIVII 

The SwMI may demand that the GCKs currently associated with the groups are disassociated forcing the groups to 
revert to using CCK (for security class 3 systems). This is done by setting the "GCK select number" element to the 
value for "No GCKN selected". 
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If in either case, the SwMI requests the MS to associate keys with GSSIs that the MS does not possess, the MS can 
reject the association and indicate the status of this back to the SwMI. If the SwMI requests the MS to associate keys 
with a range of GSSIs, and the MS does not have GSSIs either at the end points of the range, or elsewhere in the range, 
it should still accept and maintain this association in case groups are subsequently loaded within this range. 

When using DGNA SS-DGNA defined in EN 300 392-12-22 [7] the "security related information" field includes GCK 
select number only to associate a GCK to the address defined in the core of the SS-DGNA message. 

4.5.5 Notification of key cinange over tine air 

The MM security function of the BS/SwMI shall use the exchange shown in figure 38 to inform registered MSs of a 
future key change. In each case the SwMI should have previously distributed the new cipher key using the key 
management mechanisms described in clauses 4.5.1 to 4.5.3. 

The D-CK CHANGE DEMAND/U-CK CHANGE RESULT shall be used to explicitly inform the MS of the time when 
a key shall be considered valid. The time may be described as either a value representing IV (composed of slot number, 
frame number, multiframe number and hyper frame number), or a time based upon TETRA network time as described 
in EN 300 392-2 [2]. The key-id shall be one of CCK-id, SCKN, and GCKN. The scope of the D-CK CHANGE 
DEMAND/U-CK CHANGE RESULT protocol exchange is the current cell. 

On receipt of D-CK CHANGE DEMAND by MS-MM the indicated key and associated parameters shall be notified to 
the MAC using the MLE-ENCRYPTION request primitive. When the key is applied the MAC shall inform MS-MM of 
the change using the MLE-ENCRYPTION confirm primitive. If requested the MS-MM shall acknowledge the D-CK 
CHANGE DEMAND using the U-CK CHANGE RESULT PDU. 

If the MS does not possess the key it shall request the key from the SwMI using the appropriate OTAR request PDU. 
The MS shall randomize the sending of the OTAR request over the time interval between reception of D-CK CHANGE 
DEMAND and the actual time when the change will occur. If the OTAR request is not sent before leaving the cell or 
detaching from the SwMI the requirement to request the key shall be cancelled. 

Acknowledgement of D-CK CHANGE DEMAND shall be made for ITSI based key delivery using the U-CK 
CHANGE RESULT PDU by setting the "acknowledgement flag" element on the downlink PDU to "1". If this is set to 
"1", the MS shall acknowledge whether the demand changes the MS's state or not. 

The D-CK CHANGE DEMAND may also be transmitted addressed to a group of MSs or the broadcast address. In this 
case the acknowledgement is optional, either acknowledgement shall not be requested by setting the "acknowledgement 
flag" element to FALSE, or if acknowledgement is requested the MS shall start timer T371 with a randomly selected 
value on receipt of the D-CK CHANGE DEMAND. However, even if the "acknowledgement flag" = "1", the MS shall 
only acknowledge if the D-CK CHANGE DEMAND changes its state, i.e. it has not already received and stored the 
result of the same key change command. The procedure for randomly selecting the signalling slot shall follow the 
procedure for "Choosing from a new access frame" as defined in EN 300 392-2 [2], clause 23.5.1.4.6. On expiry of 
T371, the MS responds with a U-CK CHANGE RESULT PDU. The value of T371 shall be such that the 
acknowledgement is received by the SwMI before the time that the key becomes valid. 

The value of T371 shall be randomized over the time interval between receipt of the PDU and the time identified in the 
PDU for the key change. 



£75/ 



70 



ETSI TS 100 392-7 V2.4.1 (2006-10) 



MSC Key_change_General 



This shows how the MLE-ENCRYPTION 
primitives loadanewCKto layer 2 



MS MM 



BS MM 



Class 3 or Class 2 



New Key provided 



D CK CHANGE DEMAND 



MS MAC 



MLE_ENCRYPTION_request 



(CK, Time, RX&TX) 



MLE ENCRYPTION Confirm 



( Key Type, Keyld, Time) 



BS MAC 



MLE_ENCRYPTION_request 



{CK,Time, RX&TX) 



MLE ENCRYPTION Confirm 



New CK in use at layer 2 



U CK CHANGE RESULT 



(Key Type ) 



Figure 38: Key change protocol 
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4.5.5.1 Change of DCK 

DCK shall be changed explicitly using the authentication protocols described in clause 4.4.2. 
The DCK in use shall change at the following times: 

• on successful authentication; 

• if a DCK has been previously established and is in use it shall be retained throughout the authentication 
protocol and only discarded after confirmation of the success of the authentication. 

The new DCK shall be considered valid after the last repeat of the PDU containing the result Rl or R2 (as 
authentication PDUs are transmitted using layer 2 acknowledgement the receipt of the acknowledgement of the 
RESULT PDU shall be the trigger to invoke the new DCK). The MS and SwMI shall be synchronized at this time. 

4.5.5.2 Change of CCK 

The SwMI may administer the change of CCK using the D-CK-CHANGE-DEMAND PDU. Each cell in an LA shall 
update the CCK in use as indicated in the D-CK-CHANGE-DEMAND PDU. 

NOTE 1 : It is at the discretion of the SwMI how much warning of CCK change is given. 

The SwMI MM shall notify all MSs in the cell of the new CCK-id in the S YSINFO broadcast and in the header of the 
MAC-RESOURCE PDU described in clause 6.5. L 

NOTE 2: When the SwMI changes the CCK for downlink, it will still receive two slots where ESIs are encrypted 
with the old CCK on the uplink. For the duration of these two slots the SwMI shall use old CCK for 
decrypting ESI addresses in the uplink and new CCK for encrypting in the downlink. 

For change of CCK the D-CK-CHANGE-DEMAND may be addressed to group and broadcast addresses. 

4.5.5.3 Change of GCK 

The SwMI may administer the change of GCK using the D-CK CHANGE DEMAND PDU. Where the procedure is 
used the D-CK CHANGE DEMAND PDU may be addressed to group and broadcast addresses. 

The SwMI may choose to link the crypto-periods of all GCKs on the network, in this case all GCKs have the same 
GCK-VN and only one GCK-VN need be conveyed to the MS. If the SwMI supports the latter mechanism, a short 
GCK-VN (representing the 2 least significant bits of the GCK-VN) shall be conveyed in the Security Information 
Element of SYSINFO, with the full GCK-VN provided using D-CK CHANGE DEMAND with Key Change Type of 
"All GCKs". 

4.5.5.4 Change of SCK for TMO 

If over the air cipher key selection is provided the SwMI may administer the change of SCK using the D-CK CHANGE 
DEMAND PDU. This shall be performed across the entire network. 

The SwMI MM shall notify all MSs in the cell of the new SCKN/SCK-VN in the SYSINFO broadcast, and SCK-VN in 
the header of the MAC-RESOURCE PDU described in clause 6.5. L 

NOTE: When the SwMI changes the SCK for downlink, it will still receive two slots encrypted with the old SCK. 
For the duration of these two slots the SwMI shall use old SCK for decrypting ESI addresses and message 
contents in the uplink and new SCK for encrypting in the downlink. 

For change of SCK the D-CK CHANGE DEMAND may be addressed to group and broadcast addresses. 
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4.5.5.5 Change of SCK for DMO 



The "SCK use" element in the OTAR SCK PDU shall indicate whether the SCK is to be used for DMO or TMO 
operation. The SwMI may use the D-CK CHANGE DEMAND PDU to inform the MS which SCK(s) are in use for 
Direct Mode Operation (DMO). The use of SCK in DMO shall be indicated in the "SCK use" element. The change of 
SCK may be immediate or instead occur on a specific IV/network time. The SwMI may indicate whether one or several 
specific SCKs are to be used, or whether a complete subset of SCKs is to be used. In the latter case, the SwMI shall 
indicate the relevant subset. If a complete subset is to be changed at the same time, the SwMI shall ensure that the SCK- 
VNs of all SCKs in the subset are the same. The SCK-VN common to all SCKs to be made active shall be included in 
the D-CK CHANGE DEMAND PDU. 

If an MS receives a D-CK CHANGE DEMAND PDU and does not have the SCK-VN for either an individual SCK, or 
for a subset of SCKs, then it may request OTAR of new SCKs. 

4.5.5.6 Synchronization of Cipher Key Change 

When the D-CK CHANGE DEMAND PDU is used to indicate a change of cipher key or security class of the LA, the 
"Time Type" element shall be used to indicate the exact moment of change and may take one of the following forms: 

• Absolute IV: the SwMI shall activate the new cipher key on the indicated IV. In this case all 16 bits of the 
hyperframe number shall be used; 

• Network time: the SwMI shall activate the new cipher key on the Network time. If the Network time falls 
between slot boundaries, the SwMI shall round up to the next slot number of the downlink; or 

• Immediate: the SwMI shall activate the new cipher key on the first slot of the first frame of the next downlink 
multiframe. 

When D-CK CHANGE DEMAND is used to indicate a change of cipher key and/or security class, the security 
parameters transmitted in MAC-SYSINFO shall also be synchronized with the change of cipher key or security class. 



4.5.6 Security class change 



The SwMI may send D-CK CHANGE DEMAND on control channels and on assigned channels to invoke transitions 
between any of the following security classes: 

• Security Class 1; 

• Security Class 2; 

• Security Class 3 without GCK; 

• Security Class 3 with GCK. 

NOTE: Conceptually, "Security Class 3 with GCK" shall be treated as a separate security class. 

In order to avoid unnecessary re-registration attempts by registered MS during security class changes (described above), 
the following behaviour is expected from the MS: 

• if an MS had registered with Ciphering On in Security Class 2, or Security Class 3, or Security Class 3 with 
GCK, and the cell subsequently transitions to Security Class 1, then the MS shall temporarily override its 
registered ciphering mode with Ciphering Off, and shall remain registered providing it supports Security 
Class 1. Furthermore, if the cell subsequently transitions to Security Class 2, or Security Class 3, or Security 
Class 3 with GCK, then the MS shall resume its previous ciphering mode (i.e. prior to the override) of 
Ciphering On, and shall remain registered providing it supports the new security class and possesses the 
relevant key material for that security class. However, if the MS is unable to support the resumed ciphering 
mode of Ciphering On in the new security class, then the MS shall either re-register to request Ciphering Off 
or perform cell re-selection, whichever is most appropriate. 
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If an MS had registered with Ciphering On in Security Class 2, or Security Class 3, or Security Class 3 with 
GCK, and the cell subsequently transitions to Security Class 2, or Security Class 3, or Security Class 3 with 
GCK, then the MS shall continue to use the existing ciphering mode of Ciphering On, and shall remain 
registered providing it supports the new security class and possesses the relevant key material for that security 
class. However, if the MS is unable to support the same ciphering mode of Ciphering On in the new security 
class, then the MS shall either re-register to request Ciphering Off or perform cell re-selection, whichever is 
most appropriate. 

If an MS had registered with Ciphering Off in Security Class 2, or Security Class 3, or Security Class 3 with 
GCK, and the cell subsequently transitions to Security Class 1, or Security Class 2, or Security Class 3, or 
Security Class 3 with GCK, then the MS shall continue to use the existing ciphering mode of Ciphering Off. 
However, if the MS needs to change its ciphering mode to Ciphering On following the security class change, 
then the MS shall either re-register to request Ciphering On or perform cell re-selection, whichever is most 
appropriate. 

If an MS had registered with Ciphering Off in Security Class 1 and the cell subsequently transitions to 
Security Class 2, or Security Class 3, or Security Class 3 with GCK, then the MS shall re-register to negotiate 
a ciphering mode that is acceptable to the SwMI which may result in the MS continuing to use Ciphering Off. 

If the MS supports the new security class but needs to obtain the relevant key material, then the MS shall 
re-register to obtain the keys through OTAR. 

If the MS does not support the new security class or does not support OTAR of the relevant key material then 
the MS shall invoke cell re-selection procedures. 



4.5.6.1 Change of security class to security class 1 

The SwMI may use the D-CK CHANGE DEMAND PDU to inform the MS that the security class of the cell will 
change to security class 1. In this instance, the SwMI shall identify no cipher key as being active. The change of 
security class may be immediate or occur on a specific IV/network time. 

The SwMI shall set the "Change of security class" element of D-CK CHANGE DEMAND to "Transition to security 
class 1", and set the "Key change type" element to "No cipher key". 

4.5.6.2 Change of security class to security class 2 

The SwMI may use the D-CK CHANGE DEMAND PDU to inform the MS that the security class of the cell will 
change to security class 2. In this instance, the SwMI shall identify the active SCKN and SCK-VN. The change of 
security class may be immediate or occur on a specific IV/network time. 

The SwMI shall set the "Change of security class" element of D-CK CHANGE DEMAND to "Transition to security 
class 2", and set the "Key change type" element to "SCK" and set the "SCK use element" to "TMO". 

4.5.6.3 Change of security class to security class 3 

The SwMI may use the D-CK CHANGE DEMAND PDU to inform the MS that the security class of the cell will 
change to security class 3. In this instance, the SwMI shall identify the active CCK-id. The change of security class may 
be immediate or occur on a specific IV/network time. 

The SwMI shall set the "Change of security class" element of D-CK CHANGE DEMAND to "Transition to security 
class 3", and set the "Key change type" element to "CCK". 

NOTE: If the "DCK retrieval during initial cell selection" is not supported by the SwMI, the MS may consider the 
previously established DCK to be valid only if the DCK has been generated after the last ITSI-Attach or 
migration location updating in this SwMI. If the SwMI does not support the "DCK retrieval during cell 
re-selection", the MS may consider the previously established DCK to be valid only if the DCK has been 
last used within this LA and after the last ITSI-Attach or migration location updating. 
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4.5.6.4 Change of security class to security class 3 with GCK 

The SwMI may use the D-CK CHANGE DEMAND PDU to inform the MS that the security class of the cell will 
change to security class 3 with GCK. In this instance, the SwMI shall identify the active CCK-id and GCK-VN. The 
change of security class may be immediate or occur on a specific IV/network time. 

The SwMI shall set the "Change of security class" element of D-CK CHANGE DEMAND to "Transition to security 
class 3", and set the "Key change type" element to "Class 3 CCK and GCK activation". 

4.5.7 Notification of key in use 

When the D-CK CHANGE DEMAND PDU is used to indicate an active cipher key, the "Change of Security Class" 
element shall indicate "No change of Security Class ", and "Time Type" element shall be set to indicate "Currently in 
use". This may be used by the SwMI to indicate the following information to the MS: 

• the current GCK-VN for all GCKs; 

• the current SCKN and SCK-VN of a fallback SCK for the SwMI; 

• the current SCKN and SCK-VN of a DM-SCK(s) associated with DMO; or 

• the current subset of SCKs for a subset of DM-SCKs associated with DMO. 

4.5.8 Notification of GCK Activation/Deactivation 

When the D-CK CHANGE DEMAND PDU is used to indicate activation or deactivation of GCKs in the cell, the "Key 
Change Type" shall be set to either "GCK Activation" or "GCK De-activation" respectively. This shall be synchronized 
with the change of the "GCK Supported" information element in S YSINFO. 

4.5.9 Deletion of SCK, GCK and GSKO 

Prior to key deletion using the mechanisms described in this clause there should be no associations to groups for those 
keys that are to be deleted. 

The SwMI should be authenticated by the MS before keys or key associations are deleted, this may be explicit or 
implicit. 

The deletion of the TM-SCK in a class 2 SwMI using the mechanisms described in this clause should be carefully 
considered. 

NOTE: EN 300 812 [4] does not support a delete mechanism. 

The SwMI may delete SCKs, GCKs or GSKOs currently contained within an MS by an explicit Key Delete command. 
The SwMI shall send a D-OTAR Key Delete Demand PDU to the MS. The PDU shall be sent to MSs individually, it 
shall not be sent to groups of MSs. 

If a single or a list of SCKs is to be deleted, the SwMI shall set the "Key delete type" element to "Individual SCK(s)", 
and shall list the SCKNs of the keys to be deleted. The MS shall delete the required key(s) and shall respond with a 
U-OTAR Key Delete Result PDU listing the SCKs that have been deleted. If the MS cannot delete one of the keys, for 
example if it does not possess the requested key, it shall not include that SCKN in the responding PDU. Therefore, if 
deletion of a single SCK was requested, but the MS does not possess the SCK, the "number of SCKs deleted" element 
shall be set to zero and no "SCKN" element shall be included in the PDU. 
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If the SCK set is divided into subsets for DMO use, and a complete KAG is to be deleted (for example to remove all 
keys associated with a particular GSSI), the SwMI shall set the "Key delete type" to "SCK subset", and shall indicate 
the number of SCKs to be deleted per subset in the "Number of SCKs deleted" element (which is also the number of 
SCKN elements to be provided in the PDU). The SCKN elements shall only correspond to the SCKNs in the first subset 
of SCKs, i.e. the subset with SCKN = 1 as its lowest value. Therefore if multiple SCKNs are included in the PDU, the 
MS shall delete a number of SCKs equal to the "Number of SCKs deleted" element multiplied by the number of subsets 
in use. 

EXAMPLE: If the SwMI and MS use 3 subsets of 10 keys each, corresponding to "SCK subset grouping type" 
element value of 010, and the SwMI instructs the MS to delete SCKN = 3 and SCKN = 7, 
(i.e. "Number of SCKs deleted" is 2), the MS shall also delete SCKNs = 13, 17, 23 and 27. 

The MS shall respond with the U-OTAR Key Delete Result PDU indicating the SCKs deleted. It shall indicate to the 
SwMI the SCK subset grouping in use, and indicate which keys have been deleted by reference to the SCKNs in the 
first set only. If the MS does not possess any of the sets of members required, it shall omit those SCKNs from the 
U-OTAR Key Result PDU. 

If the SCK set is divided into subsets for DMO use, and an entire subset is to be deleted, the SwMI shall set the "Key 
delete type" element value to "SCK subset" to indicate deletion of an entire subset, and shall include the subset 
grouping and subset number in the corresponding elements. Only one subset shall be deleted by a single PDU, and the 
SwMI shall send further PDUs if the deletion of more than one subset is required. The MS shall respond with the same 
element values in the U-OTAR Key Delete Result PDU. If the MS is not using the subset grouping proposed by the 
SwMI, it shall not delete the requested SCKs, and it shall instead indicate a mismatch by setting the "SCK subset 
grouping" element in the U-OTAR Key Delete Result PDU to "SCK grouping not vaUd" and the "SCK subset number" 
element to "0000". 

If the SwMI requires the MS to delete all SCKs, it shall indicate this by setting the "Key delete type" element to "All 
SCKs". The MS shall delete all SCKs and respond with the same value of "Key delete type" element in the U-OTAR 
Key Delete Result PDU. 

If the SwMI requires the MS to delete one or more GCKs, it shall indicate this by setting the "Key delete type" element 
to "Individual GCKs", it shall indicate the number of GCKs to be deleted in the "Number of GCKs deleted" element 
and list the GCKNs. The MS shall delete all versions (i.e. all corresponding GCK-VNs) of the required GCKN if it has 
more than one version stored. The MS shall indicate the GCKNs deleted back to the SwMI with the U-OTAR Key 
Delete Result PDU. If it cannot delete any of the GCKs because it is not provisioned with them, it shall omit these from 
the list. Therefore, if deletion of a single GCK was requested, but the MS does not possess the GCK, the "number of 
GCKs deleted" element shall be set to "0000" and no "GCKN" element shall be included in the PDU. 

If the SwMI requires the MS to delete all GCKs, it shall indicate this by setting the "Key delete type" element to "All 
GCKs". The MS shall delete all GCKs and respond with the same value of "Key delete type" element in the U-OTAR 
Key Delete Result PDU. 

If the SwMI requires the GSKO to be deleted, it shall indicate this by setting the "Key delete type" element to "GSKO". 
The MS shall delete the GSKO and respond with the same value of "Key delete type" element in the U-OTAR Key 
Delete Result PDU. If the MS contains more than one version of GSKO, it shall delete all versions (i.e. all values of 
GSKO-VN). It shall additionally send the GSKO-VN in the U-OTAR Key Delete Result PDU: if more than one version 
of GSKO-VN was held by the MS, it shall send the highest value of GSKO-VN that it possessed. 

Figure 38a shows the message sequence chart for the key deletion protocol. 
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MSC KeyDelete 



MS 



SwMI 



D OTAR KEY DELETE DEMAND 



( KeyDelete Type, KeyParameters) 



U_OTAR_KEY_DELETE_RESULT 



(KeyDeleteType, ResultAndKeyParameters ) 



Figure 38a: Message sequence chart showing key deletion 



4.5.10 Air Interface Key Status Enquiry 



The SwMI shall be able to discover the current numbers and versions of air interface keys held by an MS by means of a 
status enquiry. The purpose of this mechanism is to allow a SwMI to maintain a record of the MS keying state, without 
needing to explicitly update the MS with new key material to force a response, which can make intensive use of air 
interface bandwidth. 

The SwMI shall send a D-OTAR Key Status Demand to the MS. It may be individually or group addressed. The SwMI 
may request the state of: 

a single SCK, specified by SCKN; 

a subset of SCKs used for DMO, identified by the SCK subset grouping pattern used and SCK subset number; 

allSCKsintheMS; 

a single GCK, identified by GCKN; 

all GCKs in the MS; or 

the GSKO or multiple versions of GSKOs in the MS. 

The MS shall respond with a U-OTAR Key Status Response containing key number (if applicable) and version number 
of the requested keys, if it has them. 

If the SwMI requests the status of an individual SCK, identified by SCKN, and the MS possesses the SCK requested, 
the MS shall respond setting the "Number of SCK status" element to a value of "1" and shall include a single "SCK 
data" element containing the SCKN and SCK-VN of that SCK. If the MS does not possess the SCK requested, it shall 
set the "Number of SCK status" element to "0" and shall not provide any "SCK data" element. 
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If the SwMI requests the status of a subset of SCKs as used for DMO, it shall include the subset grouping pattern in use 
and the subset number requested. The MS shall respond with the SCK subset grouping and SCK subset number 
requested, and shall indicate how many SCKs it is providing data for in the "Number of SCK status" element, and shall 
provide this number of "SCK data" elements, each containing SCKN and SCK-VN for one key. If the MS does not use 
the SCK subset grouping pattern demanded by the SwMI (i.e. the MS uses a different pattern), it shall set the "SCK 
subset grouping" element to "SCK grouping not valid" and the "SCK subset number" element to "00000" indicating a 
grouping mismatch. It shall set the "Number of SCK status" element to "0" and shall not provide any SCK data 
elements. If the MS has the same pattern as indicated by the SwMI, but does not have any keys in the subset, it shall set 
the "SCK subset grouping" and "SCK subset number" elements to the values in use, shall set the "Number of SCK 
status" element to "0", and shall not provide any "SCK data" elements. 

If the SwMI requests the status of all SCKs in the MS, the MS shall respond indicating how many SCKs it is providing 
data for in the "Number of SCK status" element, and shall provide this number of "SCK data" elements, each containing 
SCKN and SCK-VN for one key. If the MS does not possess any SCKs, it shall set the "Number of SCK status" 
element to "0" and shall not provide any "SCK data" element. 

If the SwMI requests the status of an individual GCK, identified by GCKN, and the MS possesses the GCK requested, 
the MS shall respond setting the "Number of GCK status" element to a value of "1" and shall include a single "GCK 
data" element containing the GCKN and GCK-VN of that GCK. If the MS does not possess the GCK requested, it shall 
set the "Number of GCK status" element to "0" and shall not provide any "GCK data" element. 

If the SwMI requests the status of all GCKs in the MS, the MS shall respond indicating how many GCKs it is providing 
data for in the "Number of GCK status" element, and shall provide this number of "GCK data" elements, each 
containing GCKN and GCK-VN for one key. One PDU allows the MS to give the SwMI the status of 3 1 GCKs. If the 
MS possesses more than 31 GCKs, it shall send further U-OTAR Key Status Response PDUs containing the extra 
GCKs. If the MS does not possess any GCKs, it shall set the "Number of GCK status" element to "0" and shall not 
provide any "GCK data" element. 

If the SwMI requests the status of the GSKO in the MS, the MS shall respond indicating how many GSKO versions it is 
providing data for in the "Number of GSKO status" element, and shall provide this number of "GSKO-VN" elements, 
each containing GSKO-VN for one key. One PDU allows the MS to give the SwMI the status of 3 GSKO-VNs. If the 
MS possesses more than 3 versions of GSKO, it shall send further U-OTAR Key Status Response PDUs containing the 
extra GSKO-VNs. If the MS does not possess any GSKOs, it shall set the "Number of GSKO status" element to "0" and 
shall not provide any "GSKO-VN" element. 

If the SwMI sends the request to a group of MSs, each MS shall respond on expiry of random timer T371. The SwMI 
shall send the maximum value of T371 to the MS in the request PDU. If the request is sent to an individual MS, the 
"max response timer value" shall be set to "0". If the MS needs to detach from the SwMI before sending the status 
response to the SwMI, it shall consider T371 to have expired and shall send the acknowledgement before detaching. 
T371 is described in clause 4.5.2.3. If the MS is unable to send the response PDU before detaching, it should store the 
PDU and send it next time it attaches to the SwMI, even if is switched off and on again in the meantime. 
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MSC KeyStatus 



MS 



SwMI 



D_OTAR_KEY_STATUS_DEMAND 



( KeyStatusType, KeyParameters) 



U_OTAR_KEY_STATUS_RESPONSE 



(Result, KeyResponseParameters ) 



Figure 38b: Message sequence chart of key status inquiry 

4.5.1 1 Crypto management group 

Use of CMG is optional but if used shall be as defined in this clause. 

A set of MSs with common key material (SCKs, GCKs) shall be considered to be part of the same Crypto Management 
Group (CMG), and to reduce the load at the air interface, group addressed OTAR signalling shall be sent to the CMG as 
a whole. The group address may be provisioned over the air interface using the method described in this clause. 

The CMG has the following attributes: 

• common set of key material (SCKs, GCKs); 

• common key encryption key (GSKO); 

• common means of addressing for group addressed OTAR (i.e. common GSSI programmed specifically for key 
management purposes). 

An MS shall be a member of zero or only one CMG. 

TM-SCK and GCK identities (SCKN and GCKN) are unique per system irrespective of the number of CMGs in use. If 
CMGs exist on a system DM-SCK identities (SCKN) are unique per CMG, else per system. 

To make use of the CMG the MS shall be provided with a GTSI for use with group addressed OTAR. The SwMI may 
provide this to the MS using D-OTAR CMG GTSI PROVIDE PDU or within D-OTAR GSKO PROVIDE PDU. The 
SwMI shall only send these PDUs to an individually addressed MS, and it shall not send these PDUs to a group of MSs. 
The MS shall respond using U-OTAR CMG GTSI RESULT PDU or U-OTAR GSKO RESULT PDU respectively. The 
MS shall then act upon OTAR messages sent to this group, as well as to messages sent to the MS's ITSI. It shall ignore 
OTAR sent to any other group address. 

The GTSI used for CMG purposes shall be considered long term and maintained in the MS even when powered down 
and up again. 

If the SwMI wishes to delete the GSSI in the MS, it shall set the "GSSI" element to "0". 

If the MS receives a CMG GTSI from the SwMI that is different to that already stored, then the MS shall delete all 
previously stored DMO SCK (i.e. where 1 < SCKN < 30), GCK and GSKO material. The fallback SCK for TMO 
(SCKN = 31 or SCKN = 32) should not be deleted. 
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4.5.12 OTAR retry mechanism 



When registered on a cell, the MS shall monitor the OTAR Retry Interval element setting, conveyed through 
transmissions of SCK, GSKO and GCK OTAR Provide PDUs, in order for the MS to determine how many hyperframes 
it shall wait before retrying an OTAR Demand for SCK, GSCKO or GCK. The last received OTAR retry interval 
always applies on the serving cell irrespective of whether it arrived in a Provide or Reject PDU. 

When the OTAR Retry Interval expires in the MS, the MS shall wait a further random number of random access 
signalling slots before retrying the OTAR Demand PDU. The procedure for randomly selecting the signalling slot shall 
follow the procedure for "Choosing from a new access frame" as defined in EN 300 392-2 [2], clause 23.5.1.4.6. 

The OTAR Retry Interval setting shall only have relevance to the cell on which it is broadcast; cells that comprise the 
same SwMI may use different settings. In the absence of any indication of the cell's OTAR Retry Interval setting, the 
MS shall default to using a setting of "Do not retry". However, if the MS subsequently receives a different OTAR Retry 
Interval setting from the SwMI, whilst one or more key requests are outstanding, then the MS shall retrospectively 
apply the newly received setting. 

Following cell re-selection, and registration on the new serving cell, the MS may re-request key(s) that are needed and, 
thereafter, wait the appropriate length of time given by the new serving cell (as previously stated) before retrying its 
OTAR Demand for SCK, GSKO or GCK. In the absence of any indication of the new serving cell's OTAR Retry 
Interval setting, the MS shall default to using a setting of "Do not retry". 



Enable and disable mechanism 



NOTE: Without authentication capability in the MS it is possible that a SwMI (real or false) can temporarily deny 
service to the MS, if the MS supports temporary enable/disable. The use of authentication embedded into 
the enable/disable mechanism as described in this clause minimizes this risk. 

An MS moving from DMO to TMO, or from TMO to DMO, shall retain its disabled state. Thus if an MS is disabled in 
TMO it shall remain disabled even if the user attempts to switch to DMO. 



5.1 General relationships 



Figure 39 shows the relationship of subscription, identified by ITSI, and the hardware of the MS, identified by TEL The 
TEI is fixed and associated with the hardware of the MS. The subscription, identified by ITSI, may be contained in a 
separable module. If ITSI is not contained in a separable module, it may still be changed by, for example, field 
programming equipment. 
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If a SIM is used to store the ITSI the procedures described in EN 300 812 [4], clause 1 1.4.4 shall be enforced in 
addition to the protocols described in this clause. 

ITSI and TEl are described in EN 300 392-1 [1], clause 7. 



\/ 



User subscription 

(possibly in user 
information module) 



(ITSI) 



MS 
EQUIPMENT 



(TEl) 



Figure 39: Relationship of TEl and ITSI in MS 



5.2 



Enable/disable state transitions 



Figure 40 shows all possible enabled and disabled states of one pair of MS equipment and ITSI and the transitions 
between the states. This diagram does not show state transitions due to separation of ITSI from, or fitting of ITSI into, 
an MS equipment. 
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7,8,9 




KEY: 

1 ) temporary disabling of equipment; 

2) temporary disabling of ITSI; 

3) temporary disabling of equipment and ITSI; 

4) permanent disabling of equipment; 

5) permanent disabling of ITSI; 

6) permanent disabling of equipment and ITSI; 

7) enabling of equipment; 

8) enabling of ITSI; 

9) enabling of equipment and ITSI. 

Figure 40: State transitions of enable/disable mechianism 



5.3 



Mechanisms 



An MS and SwMI operating in security class 3 or security class 2 shall perform enabling and disabling with encryption 
applied. An MS and SwMI operating in security class 1 shall perform enabling and disabling in clear. If authentication 
is required by the SwMI it shall be applied for enable and disable operations by the inclusion of an authentication 
challenge in the D-DISABLE or D-ENABLE PDU. 

The rules for when the MS may reject an enable/disable command are described in clause 5.4.6. 

In cases where authentication has been initiated by the SwMI it may be made mutual by the MS. 

There are nine possible transactions necessary for the enable/disable procedure which allow disable and enable of the 
MS equipment, the subscription, or both. These are detailed in clauses 5.3.1 to 5.3.6 in which the temporary and 
permanent distinctions are amalgamated. 
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There may be other mechanisms that withdraw service or disable the equipment that are outside the scope of the present 
document. 

Equipment or subscriptions that have been temporarily disabled may be enabled by the enable mechanisms described in 
clauses 5.3.4 to 5.3.6. Equipment or subscriptions that have been permanently disabled shall not be enabled by these 
mechanisms. 



5.3.1 Disable of MS equipment 



The MS equipment shall be disabled by the SwMI either temporarily or permanently in such a manner that it shall enter 
the disabled state, and remain disabled even if a separable module is used to contain the ITSI, and that module is 
changed. If the ITSI is contained in a separable module, it may be detached and connected to a different MS equipment; 
and may then operate providing that the new MS equipment has not also been disabled. 

5.3.2 Disable of an subscription 

The subscription shall be disabled by the SwMI either temporarily or permanently. If the ITSI is contained in a 
separable module, and this module is then connected to a different MS equipment, the composite MS shall remain 
disabled. The MS equipment shall operate if a different module containing a subscription containing ITSI that has itself 
not been disabled is connected. 

5.3.3 Disable of subscription and equipment 

The MS equipment and its subscription shall be disabled by the SwMI either temporarily or permanently in such a 
manner that neither the separable module nor the MS equipment shall individually function even if the module is 
connected to a different MS equipment, or the MS equipment is connected to a different module. 



5.3.4 Enable an MS equipment 



The MS shall be capable of receiving enable commands addressed individually with a valid L2 address for the MS, 
i.e. ISSI/ASSI in the home network and ITSI/(V)ASSI in a visited network (during migration). The PDU shall include 
the TEI of the MS equipment. Only MS equipment that has been temporarily disabled may be enabled by this method: 
if the MS subscription has also been disabled, whether the ITSI is contained in a separable module or not, it shall not be 
enabled by this mechanism. 

5.3.5 Enable an MS subscription 

The MS shall be capable of receiving enable commands addressed individually with a valid L2 address for the MS, 
i.e. ISSI/ASSI in the home network and ITSI/(V)ASSI in a visited network (during migration). The PDU shall not 
include the TEI of the MS equipment. Only an MS subscription that has been temporarily disabled may be enabled by 
this method: If the MS equipment has also been disabled, whether the ITSI is contained in a separable module or not, 
the composite MS shall not be enabled solely by this mechanism. 

5.3.6 Enable an MS equipment and subscription 

The MS equipment and subscription shall be enabled using commands addressed to a valid L2 individual address for 
the MS, i.e. ISSI/ASSI in the home network and ITSI/(V)ASSI in a visited network (during migration), whether the 
subscription or equipment has previously been disabled, or both. Equipment, or subscriptions, or both, that have been 
temporarily disabled may be enabled by this mechanism. The PDU shall include the TEI of the MS equipment. 
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Where the ITSI is not separable, an MS may be disabled by utilizing any of the mechanisms described in clauses 5.3.1 
to 5.3.3. However, to re-enable an MS the SwMI shall use the corresponding mechanism or a mechanism including it. 
Therefore, an MS temporarily disabled using the mechanism described in clause 5.3.1 shall only be enabled using the 
mechanisms described in clause 5.3.4 or clause 5.3.6; an MS disabled by the mechanism described in clause 5.3.2 shall 
only be enabled by the mechanisms described in clause 5.3.5 or clause 5.3.6; and an MS disabled by the mechanism 
described in clause 5.3.3 shall only be enabled by the mechanism described in clause 5.3.6. 

5.4 Enable/disable protocol 
5.4.1 General case 

NOTE 1 : An MS operating in transmission inhibit mode (for example operating in radio transmission free 

environments such as hospitals) may be unable to transmit the protocol responses required below. In such 
cases the behaviour of the MS is determined by system policy (e.g. to be permitted to act on the received 
command without response). 

All signalling should be individually addressed. The SwMI may need to know the ITSI/TEI binding, where necessary 
this may be obtained using the ITSI-TEI mapping at registration. Confirmation of the target for disabling and enabling 
is then provided by including the ITSI and/or TEI of the MS in the PDUs. If the SwMI supports authentication, it should 
authenticate the MS to ensure that it is obtaining a response from the correct MS. The MS should also authenticate the 
SwMI when possible to validate the instruction. The authentication protocol and PDUs are contained in clause 4. 

The TEI when included in PDUs is not protected by any specific cryptographic sealing mechanism. It should therefore 
only be provided when encryption parameters have been established, and air interface encryption is operating on a cell 
of class 2 or 3 as described in clause 6. 

NOTE 2: It is recommended that the TEI is not transferred across the air interface in class 1 cells. 

The enabling and disabhng is enacted by the primitives MLE-CLOSE, MLE-DEACTIVATE request and MLE-OPEN. 
The MLE-CLOSE primitive used in the context of temporary disable to indicate that access to the communication 
resources has been closed to the other higher layer entities: SNDCP and CMCE. If the disabling is temporary the MS 
shall remain disabled in the sense that access to the communication resources shall remain closed for the CMCE and 
SNDCP entities. MM should remain active so that any roaming (or associated security) functions continue to operate, in 
order to allow the MS to receive an enable instruction. Should the MS be powered down the MS shall retain the 
information that it is temporarily disabled. 

In the temporarily disabled state the MS shall disable the MMI in order to prevent the user making any change to the 
state of the MS and also to prevent the user being able to derive any knowledge of the operation of the MS. 

In the temporarily disabled state the MS shall not be able to invoke any function of the CMCE and SNDCP entities. 

EXCEPTION: For the purpose of supporting the Supplementary Service Ambience Listening the SwMI may be 
able to invoke the relevant CMCE entities. 

The MS shall not invoke any OTAR function for SCK and GCK by any method in the temporarily disabled state. In a 
permanently disabled state the disabling of all radio functions shall be carried out using the MLE-DEACTIVATE 
request. This shall be used by the MM entity to request the de-activation of all MLE procedures and to return to the 
NULL state. No communication resources are available for use after this primitive has been issued. It shall not be 
possible to reverse the permanent disable state by user intervention or by a TETRA protocol. 
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5.4.2 Status of cipher key material 

5.4.2.1 Permanently disabled state 

In the event of permanent disable of an ITSI all key material should be destroyed including K. 

In the event of permanent disable of an equipment (TEI) all key material maintained on the equipment should be 
destroyed. If a SIM is fitted entry to this state should not delete key material on the SIM. 

NOTE: A SIM is intended to store material directly related only to an ITSI. 

It is advised that where possible as a result of permanent disable algorithms should be destroyed. 

5.4.2.2 Temporarily disabled state 

In the event of temporary disable of an ITSI all shared long lifetime key material (GCK, SCK where 1 < SCKN < 30, 
GSKO) and CMG GTSI should be destroyed. The fallback SCK for TMO (SCKN = 31 or SCKN = 32), and K should 
not be deleted. 

5.4.3 Specific protocol exchanges 

The normal message exchanges for the various cases shall be according to clauses 5.4.3.1 to 5.4.3.3. 

The MS shall send U-DISABLE STATUS even if there is no resulting change in state of the MS arising from the 
ENABLE or DISABLE request. Even when no change in state occurs, the complete protocol, including authentication 
where required, shall be followed. 

5.4.3.1 Disabling an MS with mutual authentication 

The scenario in figure 41 shall apply for MS and SwMI where the SwMI enforces authentication and the MS and SwMI 
supports mutual authentication. The authentication mechanisms and PDUs are described in clause 4 of the present 
document. The MSC shows as optional the key change procedure described in clause 4.5.5.1 which shall be considered 
mandatory for class 3 cells. The use of MLE- DEACTIVATE is shown as optional and shall apply when the disabling 
type is permanent. 

Figure 41 shows the message sequence for this case. 
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MSC Disable With Autinentication 



UL 


MS_MM BS_ 


IVIIVI 






D_DISABLE 






(Intent, RAND1,RS) 
U_AUTHENTICATION_RESPONSE 






(RAND2, RES1 ) 

D_AUTHENTICATION_RESULT 






(R1,RES2) 
U_AUTHENTICATION_RESULT 






(R2) 




OPT, 








1 


Key_Change_DCK 


J 






1 




TNMM_DISABLING 


D_DISABLE 






(confirm) 








(indication) 





U DISABLE STATUS 





MS_MLE 




(Eouioment status ITSI Status ) 












MLE_CLOSE 












OPT, 


MLE_DEACTIVATE 




1 
1 























5.4.3.2 



Figure 41 : Disabling an IVIS with mutual authentication 



Enabling an MS with mutual authentication 



The scenario in figure 42 shall apply for MS and SwMI where the SwMI enforces authentication and the MS and SwMI 
supports mutual authentication. The authentication mechanisms and PDUs are described in clause 4 of the present 
document. The MSC shows as optional the key change procedure described in clause 4.5.5 which shall be considered 
mandatory for class 3 cells. 
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Figure 42 shows the message sequence for this case. 



MSC ENABLE With Authentication 



UL 



MS MM 



BS MM 



D ENABLE 



[Intent, RAND1,RS) 



U AUTHENTICATION RESPONSE 



(RAND2, RES1 ) 



D AUTHENTICATION RESULT 



(R1,RES2) 



U AUTHENTICATION RESULT 



{R2) 



OPTi 



Key_Change_DCK 



TNMM ENABLING 



(indication) 



MS MLE 



MLE OPEN 



D ENABLE 



(confirm) 



U DISABLE STATUS 



(Equipment_status, ITSI_Status 



Figure 42: Enabling an IVIS with authentication 



5.4.3.3 



Enabling an MS with non-mutual authentication 



The scenario in figure 42a shall apply for MS and SwMI where the SwMI enforces authentication but the MS does not 
support mutual authentication. The authentication mechanisms and PDUs are described in clause 4 of the present 
document. The MSC shows as optional the key change procedure described in clause 4.5.5.1 which shall be considered 
mandatory for class 3 cells. 
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Figure 42a shows the message sequence for this case. 



MSC ENABLE With NonMutualAuthentication 



UL 



MS MM 



BS MM 



D ENABLE 



l(itent, RAND1, RS ) 
U AUTHENTICATION RESPONSE 



( RES1 ) 



D AUTHENTICATION RESULT 



( R1 ) 



OPTJ 



Key_Change_DCK 



TNMM ENABLING 



(ndication ) 



MS MLE 



MLE OPEN 



D ENABLE 



(confirm ) 



U DISABLE STATUS 



( Equipment_status, ITSI_Stat^s 



Figure 42a: Enabling an IVIS with non-mutual authentication 
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5.4.3.4 



Disabling an MS with non-mutual authentication 



The scenario in figure 42b shall apply for MS and SwMI where the SwMI enforces authentication but the MS does not 
support mutual authentication. The authentication mechanisms and PDUs are described in clause 4 of the present 
document. The MSC shows as optional the key change procedure described in clause 4.5.5 which shall be considered 
mandatory for class 3 cells. The use of MLE-DEACTIVATE is shown as optional but shall apply when the disabling 
type is permanent. 

Figure 42b shows the message sequence for this case. 







MSC DISABLE_With 


_NonMutualAuthentication 










UL 




MS_MM 




BS_MM 














D_DISABLE 










l(itent, RAND1, RS ) 
U_AUTHENTICATION_RESPONSE 




( RES1 ) 

D_AUTHENTICATION_RESULT 






( R1 ) 








OPJ 














Key Change DCK 












TNMM_DISABLING 


D_DISABLE 








(confirm ) 
U_DISABLE_STATUS 










(ndication ) 
















MS_MLE 




( Equipment_status, ITSLStat^s 








MLE_CLOSE 






















1 








^^ 























Figure 42b: Disabling an IVIS with non-mutual authentication 
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5.4.4 Enabling an MS without autlnentication 

The scenario in figure 43 shall apply for MS and SwMI where the SwMI does not enforce authentication. 

MSC ENABLE Without Authentication 



UL 



MS MM 



TNMM ENABLING 



(indication) 



MS MLE 



MLE OPEN 



BS 



D ENABLE 



( Intent) 



U DISABLE STATUS 



(Equipment_status, ITSI_status ) 



Figure 43: Enabling an IVIS without authentication 
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5.4.5 Disabling an MS witinout autinentication 

The scenario in figure 44 shall apply for MS and SwMI where the SwMI does not enforce authentication. 



MSC Disable_Without_Authentication 


UL MS_MM 


BS_IV1IV1 




TNMM_DISABLING 


D_DISABLE 




U_DISABLE_STATUS 


(Intent) 


(indication) 


(Equlpment_status, ITSI_status ) 








MS_MLE 




MLE_CLOSE 









Figure 44: Disabling an IVIS without authentication 

5.4.6 Rejection of enable or disable command 

NOTE: Local security policy determines the behaviour required from the system. 

An MS which receives an enable or disable command for a function which it does not support should reject the enable 
or disable command with the message "MM PDU NOT SUPPORTED". 

An MS which supports enable/disable and encryption should reject an unencrypted enable/disable command with the 
reason "encryption is required" in the U-DISABLE STATUS PDU. 

An MS which supports enable/disable, but does not support authentication, should reject an enable/disable command 
which includes authentication with the reason "authentication not supported" in the U-DISABLE STATUS PDU. 

An MS which supports enable/disable and enforces mutual authentication should reject an enable/disable command 
which does not include authentication with the reason "authentication required" or "authentication and encryption are 
required" in the U-DISABLE STATUS PDU. 

An MS which supports enable/disable should reject an enable/disable command directed at a TEI which does not match 
the TEI of the MS with the reason "TEI mismatch" in the U-DISABLE STATUS PDU. 
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MSC Disable_Rejection 



MS MM 



BS MM 



D DISABLE 



(Intent) 



U DISABLE STATUS 



(Equipment_status, ITSI_s1atus, Result ) 



Figure 45: Rejection of permanent disabling by an IVIS without authentication 

5.4.7 MM service primitives 

MM shall provide indication to the user application when the MS has been disabled or enabled. The primitives that shall 
be provided are detailed in the following clauses. 



5.4.7.1 



TNMM-DISABLING primitive 



TNMM-DISABLING indication primitive shall be used as an indication to the user application that a temporary or 
permanent disabling of the MS is ordered. 

Table 7 defines the parameters for TNMM-DISABLING indication. 

Table 7: Parameters for the primitive TNMM-DISABLING indication 



Parameter 


Indication 


Enable/disable status 


M 
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5.4.7.2 



TNMM-ENABLING primitive 



TNMM-ENABLING indication primitive shall be used as an indication to the user application that the temporary 
disabling of the MS is cancelled. 

Table 8 defines the parameters for TNMM-ENABLING indication. 

Table 8: Parameters for the primitive TNIVIIVI-ENABLING indication 



Parameter 


Indication 


Enable/disable status 


M 



The parameters in the primitives may take the following values. 



Parameter name 


Values/Options 


Enable/disable status 


Equipment enabled 


Subscription enabled 


Equipment and subscription enabled 


Equipment temporary disabled 


Equipment permanently disabled 


Subscription temporary disabled 


Subscription permanently disabled 


Equipment and subscription temporarily disabled 


Equipment and subscription permanently disabled 



6 Air Interface (Al) encryption 

6.1 General principles 

AI encryption shall provide confidentiality on the radio link between MS and BS and be resident in the upper part of the 
MAC layer of the TETRA protocol stack, which itself is the lower part of layer 2. Situating the encryption process at 
this point, prior to channel coding at the transmitting end and after channel decoding at the receiving end, enables the 
MAC headers to be left unencrypted. This allows the appropriate channel coding to be used, enables receiving parties to 
determine the applicability of a message received over air for them, and enables application of the correct key for the 
decryption process. Figure 46 illustrates this placement. 
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C-Plane 



TNMM-SAP 



Authentication, key management 



LMM-SAP 
I 



L3 

MM/MLE 



MLE 



U-Plane 



\ 

Signalling 



± 



TMD-SAP - - TLA-SAP 



\ 

Encryption Control 



TLC-SAP 



LLC-frame 
functions 



Al encryption, 

traffic and signalling 

functions 



Al key 
management 



Upper MAC 



Layer 

management 

functions 



L2 



Channel coding, scrambling, 
interleaving and slot stealing 



TP-SAP 



Lower MAC 



TPC-SAP 



I I LI 

Physical Layer 

Figure 46: Relationship of security functions to layers functions in IVIS 

If an MS and SwMI load different keys from each other, the receiving party will decode messages incorrectly. This will 
cause erroneous operation. The result of this, and any corrective action put in place to prevent errors, for example 
attempting a re-authentication to establish new keys, is outside the scope of the present document. 

Air interface encryption shall be a separate function to the end-to-end encryption service described in EN 302 109 [6]. 
Information that has already been encrypted by the end-to-end service may be encrypted again by the air interface 
encryption function. Where TETRA provides for clear or encrypted circuit mode services in clause 8 of 
EN 300 392-1 [1], these shall be independent of air interface encryption; thus a circuit mode service invoked without 
end-to-end encryption may still be encrypted over the air interface. 



6.2 Security class 



Two encryption modes are described, each of which shall use the same encryption process: 

SCK mode: For Al encryption without enforced authentication. This mode shall use SCK for address 

encryption. 

DCK mode: For Al encryption where authentication is mandatory. This mode shall use CCK for address 

encryption, and shall also use CCK to encrypt group addressed signalling (including broadcast) 
and traffic alone or in combination with GCK. 
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Table 9 summarizes the encryption modes into a set of three security (equipment) classes. These classes apply to cells 
within a SwMI and may be used to classify terminal capability. 

Table 9: Security classes 



Class 1 : 


Shall not use encryption. 


May use authentication. 


Class 2: 
SCK Mode 


Shall use SCK encryption. 


Shall use ESI with SCK. 


May use authentication. 


Class 3: 
DCK Mode 


Shall use authentication. 


Shall use DCK, CCK and may use MGCK encryption (GCK in combination with CCK). 


Shall use ESI with CCK. 



Table 10: Void 

The present document describes a system in which all signalling and traffic within that system comply with the same 
security class. However, signalling permits more than one security class to be supported concurrently within a SwMI, 
and movements between these classes are described in the present document. The SwMI shall control the state of AI 
encryption. 

An MS may support one, several, or all security classes. Each shall support at any one time one of the following 
options: 

• class 1 only; 

• class 2 only; 

• class 2 and class 1; 

• class 3 only; or 

• class 3 and class 1. 

Class 2 and class 3 are not permitted to be supported at the same time in any cell because of address conflicts that could 
arise from using short identity encryption with two different keys. 

In class 3 systems post authentication all individually addressed signalling exchanges on the downlink, and all 
signalling exchanges on the uplink, are also implicitly authenticated by use of DCK as the encryption key. In group 
addressed signalling exchanges protected by MGCK implicit authentication is also provided in class 3 systems as the 
CCK can only be received if the MS is in possession of DCK. 

6.2.0 Notification of security class 

The security class and other parameters shall be broadcast by each cell in the SYSINFO element contained in the 
Broadcast Network Channel (BNCH) (see EN 300 392-2 [2], clause 21). The broadcast shall use the Extended Service 
Broadcast information element defined in EN 300 392-2 [2] table 334a and signalled by setting the "Optional Field 
flag" element of SYSINFO to 1 12. It should be noted that SYSINFO may not always contain security parameters as the 
Extended Service Broadcast element can be alternated with one or more of the following information fields: Even 
multiframe definition for TS mode; Odd multiframe definition for TS mode; or. Default definition for access code A. 
Systems employing the security provisions described in the present document should ensure regular broadcast of the 
security parameters. 

6.2.0.1 Security Class of Neighbouring Cells 

The serving cell may indicate the security class capabilities of neighbouring cells through the "Timeshare cell and AI 
encryption information" information element in D-NWRK BROADCAST. The MS should assume that the neighbour 
cells have the same security class as that of the serving cell (i.e. the network is homogenous), unless the MS is given 
information to the contrary through this information element. 
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6.2.0.2 Identification of MS security capabilities 

An MS shall register to the SwMI at the highest security class mutually available to the MS and SwMI (i.e. if BS 
supports class 3 and class 1 MS, and the MS also supports class 3 and class 1, the MS shall register at class 3). 

The MS shall use the fields present in the class of MS element (see EN 300 392-2 [2], table 167) to indicate at 
registration the authentication, DCK encryption and SCK encryption capabilities of the MS for security. Furthermore, 
when registering for SC3 operation, the MS shall use the additional fields available in the Cipher Parameters element to 
indicate the MS's support for TM-SCK OTAR, SDMO and DM-SCK OTAR, and GCK encryption/OTAR. 

NOTE: When registering for SC2 operation, the MS is unable to indicate its support for TM-SCK OTAR, SDMO 
and DM-SCK OTAR, and GCK encryption/OTAR. 

Table 11: Void 

The TETRA Air Interface standard version number given in EN 300 392-2 [2], table 167, applies for value OOO2 to 
ETS 300 392-2 edition 1 only (see bibliography). Value OOlj shall apply to ETS 300 392-2 edition 1, plus 
EN 300 392-7 (v2.3.1). Value OlOj shall apply to EN 300 392-2 [2] plus EN 300 392-7 (v2.3.1). There shall be no 
signalling to indicate that an MS complies with ETS 300 392-7 (see bibliography), implying that ETS 300 392-7 is not 
accepted as a valid implementation. 

This edition of the present document is compatible with EN 300 392-7 v2.1.1. 

6.2.1 Constraints on LA arising from cell class 

In a fully operational LA, all cells should be of the same security class (see also clause 6.5.1.3 and constraints defined 
for periods of class change in clause 4.5.6). 

6.3 Key Stream Generator (KSG) 

Encryption shall be realized using an encryption algorithm implemented in a KSG. 

The KSG shall form an integral part of an MS or BS. 

The KSG shall have two inputs, an Initial Value (IV) and a cipher key. These parameters shall be as specified in 
clause 6.3.2. The KSG shall produce one output as a sequence of key stream bits referred to as a Key Stream Segment 
(KSS). 

A KSS of length n shall be produced to encrypt every timeslot. The bits of KSS are labelled KSS(O), ... KSS(n-l), 
where KSS(O) is the first bit output from the generator. The bits in the KSS shall be used to encrypt or decrypt the data 
of the control or traffic field. The maximum value of n shall be 432, which enables encryption of a TCH/7,2 unprotected 
traffic channel. 



6.3.1 KSG numbering and selection 



TETRA supports both standard and proprietary algorithms. Location update signalling shall identify which algorithm is 
in use. Migration should only be possible if there is agreement between operators on the algorithm used. 

The SwMI should only have one encryption algorithm. An MS may have more than one algorithm but shall use the 
algorithm indicated by the SwMI. 

Table 12 shows that the values OOOO2 to 01 1 12 of KSG number used in signalling shall be reserved for the TETRA 
standard algorithms (see also EN 300 392-2 [2], clause 16.10.29). 
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Table 12: KSG Number element contents 



Information element 


Length 


Value 


Remark 


KSG Number 


4 


OOOO2 


TETRA Standard Algorithm, TEA1 


0001 2 


TETRA Standard Algorithm, TEA2 


001 O2 


TETRA Standard Algorithm, TEAS 


0011 2 


TETRA Standard Algorithm, TEA4 


OIOO2 

to 
OIII2 


Reserved for future expansion 


IXXX2 


Proprietary TETRA Algorithms 



The TETRA standard algorithms are only available on a restricted basis. The management rules for these algorithms 
can be found at the ETSI Web Portal ( http://portal.etsi.org/dvbandca/ALGO/listtest.asp) . 

Where a SwMI supports more than one encryption algorithm in class 3 systems the CCK has to be common to users of 
all TEA algorithms, and in class 2 systems the SCK has to be common to users of all TEA algorithms, in order for 
commonality of ESI. Groups of users should be differentiated by GCK in class 3 systems. Terminals shall support only 
one active encryption algorithm. There shall be no dynamic change of registered algorithm forMSs in a session. If there 
is more than one KSG in use in the SwMI, then broadcast messages should not be encrypted. 



6.3.2 Interface parameters 



6.3.2.1 Initial Value (IV) 

The composition of the slot and frame numbering input to IV shall be as follows: 

• the first two bits IV(0) and IV(1) shall correspond to the slot number, and shall take values from to 3, where 
value corresponds to slot 1, and value 3 corresponds to slot 4. IV (0) shall be the least significant bit of the 
slot number (EN 300 392-2 [2], clause 9.3.5); 

• the next five bits IV(2) to IV (6) shall correspond to the frame number, and shall take values 

from 1 (00001 binary) to 18 (10010 binary). IV(2) shall correspond to the least significant bit of the frame 
number (EN 300 392-2 [2], clause 9.3.4); 

• the next six bits IV(7) to IV(12) shall correspond to the multiframe number, and shall take values 
from 1 (00001 binary) to 60 (111 100 binary). IV(7) shall correspond to the least significant bit of the 
multiframe number (EN 300 392-2 [2], clause 9.3.7); 

• the next 15 bits IV(13) to IV (27) shall correspond to the 15 least significant bits of an extension that numbers 
the hyper-frames. These can take all values from to 32 767. IV(13) shall correspond to the least significant 
bit of the hyper-frame numbering extension (EN 300 392-2 [2], clause 9.3.8); and 

• the final bit, IV(28), shall be used to indicate the direction of transmission and shall be given the value for 
downlink transmissions, and shall be given the value 1 for uplink transmissions. 

The value of IV shall be maintained by the SwMI and broadcast on the SYNC and SYSINFO PDUs (layer 2). The value 
of hyper-frame (IV(13) to IV (27)) shall be broadcast to a schedule determined by the SwMI with the value of CCK-id 
on cells of security class 3, and with the value of SCK-VN in cells of security class 2, in the SYSINFO broadcast. 



6.3.2.2 



Cipher Key 



The CK shall not be used directly at the air interface for encryption but shall be modified by the Colour Code (CC), 
LA-id and Carrier Number (CN) using algorithm TB5 (see figure 47). This shall randomize the input to the encryption 
algorithm amongst the carriers of a single cell and between cells in a location area. 

The ciphering process shall be as shown in figure 47. A cipher key shall be used in conjunction with a KSG to generate 
a key stream for encryption and decryption of information at the MAC layer. It can be considered a binary vector of 
80 bits, labelled ECK(O) . . . ECK(79). The cipher key used for encryption and decryption of the uplink may be different 
from the cipher key used for encryption and decryption of the downlink, as described in clause 6.5. 
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CK — ► 
CN — ► 


TBS 












LA — ► 


ECK 


KSG 






CC — ► 


► 




IV 




^ 




KSS 
Plaintext/Ciphertext fc^/T^ 


Ciphertext/Plaintext 








'KU 




► 



NOTE: CN of the main carrier, CC, LA-id, and initializing values of IV are received at tine MS from the BS 

broadcast signalling messages. After initialization IV is locally generated at the MS. When camped on a 
cell CN values are received at the MS from downlink MAC-RESOURCE and MAC-END PDUs. IV is locally 
generated at the BS. 

Figure 47: Speech and control information encryption 



6.4 Encryption mechanism 



The KSS bits shall be modulo 2 added (XORed) with plain text bits in data, speech and control channels to obtain 
encrypted cipher text bits, with the exception of the MAC header bits and fill bits. KSS(O) shall be XORed with the first 
transmitted bit of the first TM-SDU, and so on. There shall be one exception to this procedure which occurs when the 
MAC header includes channel allocation element data. This is described in clause 6.7.1.2. 

6.4.1 Allocation of KSS to logical channels 

KSS shall be allocated to TETRA logical channels as shown in table 13. Any unused bits shall be discarded. 

Table 13: KSS allocation to logical channels 



Logical channel 


Bits in channel 


KSS allocation 


TCH/2.4 


144 


KSS(124to267) 


TCH/4.8 


288 


KSS(124to411) 


TCH/7.2 


432 


KSS(0to431) 


STCH+TCH/2.4 


124 + 144 


KSS(0 to 1 23) + KSS(1 24 to 267) 


STCH+TCH/4.8 


1 24 + 288 


KSS(0 to 1 23) + KSS(1 24 to 41 1 ) 


STCH+TCH/7.2 


124 + 432 


KSS(0 to 123) + KSS(0 to 431) (see note 1) 


TCH/S (full) 


274 


KSS(0 to 273) 


STCH+TCH/S 


124 + 137 


KSS(0 to 123) + KSS(216 to 352) 


SCH/F 


268 


KSS(0 to 267) 


SCH/HU (see note 2) 


92 


KSS(0to91) 


SCH/HD+SCH/HD 


124 + 124 


KSS(0 to 123) + KSS(216 to 339) 


STCH+STCH 


124 + 124 


KSS(0to123) + KSS(216to339) 


BSCH-hSCH/HD 


60+ 124 


clear +KSS(216 to 339) 


SCH/HD+BNCH 


124 + 124 


KSS(0 to 123) + clear 


NOTE 1 : Where TCH/7.2 is stolen the first 21 6 encrypted bits of TCH/7.2 are not transmitted. 

NOTE 2: SCH/HU KSS allocation applies whether the first or second half slot is selected for transmission. 



NOTE: KSS repeat is possible only for multi-slot interleaved circuit mode data when both half slots in a single 
slot are stolen. 
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6.4.2 Allocation of KSS to logical channels with PDU association 

On the control channel, the MAC may perform PDU association, where more than one PDU may be transmitted within 
one slot. These PDUs may be addressed to different identities and may use different cipher keys. The MAC headers 
themselves may be of varying lengths. 

To allow for this, the KSS shall be restarted at the commencement of each SDU (see figures 48, 49 and 50). 

This mechanism shall apply in all control channel cases, including in the case of half slots on downlink or uplink. 



/" 
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MAC header 
left clear 
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Figure 48: Allocation of KSS to encrypt MAC PDUs 
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NOTE: Length of TM-SDU 1 is L1 , length of TM-SDU 2 is L2. 
Figure 49: Allocation of KSS to encrypt MAC PDUs with PDU Association for full slot logical channels 
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NOTE 1 : KSS1 1 (m+1 ) onwards discarded. 

NOTE 2: KSS1 2(n+1 ) onwards discarded. 

NOTE 3: KSS21 (0) to KSS21 (215) and KSS21 (p+1 ) onwards discarded. 

NOTE 4: KSS21 (0) to KSS21 (215) and KSS21 (r+1 ) onwards discarded. 

Figure 50: Allocation of KSS to encrypt MAC PDUs with 
PDU Association for half slot logical channels 

To avoid replay of key stream, the following should be avoided where PDU association takes place: 

• sending more than one SDU encrypted with the same encryption key within one logical channel. 

NOTE: For the sake of clarity figures 49 and 50 show only two MAC PDUs being associated within a full or half 
slot, but there may be more if the MAC PDUs are sufficiently small. 



6.4.3 Synchronization of data calls where data is multi-slot interleaved 

NOTE: The examples below assume that the data call is a single slot call transmitted on timeslot 1 of each frame. 

In multi-slot interleaved calls the original traffic burst is expanded to cover 4 or 8 bursts (TCH/2.4, TCH/4.8). The 
interleaving follows encryption at the transmitter, and decryption follows de-interleaving at the receiver. 
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NOTE 1 : IV5(g|.( is the value of IV used in the synchronization bursts. 
NOTE 2: Actual IV value is to be used for decryption of non-traffic bursts. 

Figure 51 : Value of IV to be used for TCH/4.8 or TCH/2.4 with interleaving depth of 4 
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The actual IV value is to be used by the receiver for the synchronization bursts and any bursts that are not (interleaved) 



traffic. The value of IV to be used in the receiver shall be 
value of IV. 



IV^ - 4 X (interleaving depth - 1)", 



Transmission across frame 18 shall be treated as shown in figure 52. 
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NOTE: IV5(g|.( is the value of IV used in the first traffic frame in this example. 

Figure 52: Treatment of IV for TCH/4.8 or TCH/2.4 with interleaving depth of 4 at frame 18 

For traffic frames starting, but not fully received, before frame 18, the value of IV to be used for encryption shall be 
"IV^ - 4 X (interleaving depth - 1) - 4", where IV^ is the actual value of IV. 

6.4.4 Recovery of stolen frames from interleaved data 

If the stolen frame has been stolen from the C-PLANE it shall not be treated as if it were interleaved and shall therefore 
be decrypted with the "actual" value of IV for immediate delivery to the C-PLANE. 

If the stolen frame has been stolen from circuit mode data in the U-PLANE it shall be treated as interleaved and shall 
follow the same rules as for data traffic. 

6.5 Use of cipher keys 

The cipher keys and their allocation are described in clauses 4.2. 1 to 4.2.4. 

The header of MAC PDUs transmitted over the air interface shall contain indication whether the MAC PDU and some 
elements of the MAC Header (SSI address and channel allocation elements) are encrypted or not. In addition the header 
of MAC downlink PDUs includes one bit that shall indicate the least significant bit of the version of CCK or SCK that 
is in use. This indication is used to assist the MS to detect if the CCK or SCK has been changed if the D-CK CHANGE 
DEMAND PDU has been missed. It can only provide this assistance when the least significant bits of the old and new 
keys are different. 

In cells of security class 2 the SCK shall be used to encrypt individual addressed signalling and traffic. SCK shall also 
be used with the identity encryption mechanism to conceal identities in use at the air interface within a SwMI. Only one 
SCK shall be in use within a SwMI at any one time except during key change period. 

In cells of security class 3 the DCK shall be used to encrypt all signalling and traffic sent from an MS to the SwMI, and 
to encrypt individually addressed signalling and traffic sent from the SwMI to the MS. 

In cells of security class 3 that support group calls a GCK may be associated with a single or multiple group addresses 
at any time. The CCK shall be used as a key modifier to produce the MGCK, which shall be used to encrypt group 
addressed signalling and traffic (see clause 4.2.2). If no GCK is assigned to a group then CCK shall be used to encrypt 
all group addressed signalling and traffic. CCK shall also be used in conjunction with the identity encryption 
mechanism to protect all SSIs used with encryption within an LA. An MS may store the CCKs in use in more than one 
LA to ease cell re-selection. 
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The use of cipher keys for security class 3 is illustrated in figure 53. 
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Figure 53: Illustration of cipher key use in class 3 system 

6.5.1 Identification of encryption state of downlink MAC PDUs 

The encryption mode element (two bits) in the header of the downlink MAC-RESOURCE PDU shall be used for air 
interface encryption management and shall indicate the encryption state of each TM-SDU for each cell security class as 
shown in clauses 6.5.1.1 to 6.5.1.3. These bits also indicate the use of the ESI mechanism. 

6.5.1.1 Class 1 cells 

In a cell supporting only class lonly the values and interpretations given in table 14 shall apply. 
Table 14: Encryption mode element in class 1 cell contents 



Information element 


Length 


Value 


Remark 


Encryption mode element 


2 


OO2 


PDU not encrypted 


Others 


Reserved 
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6.5.1.2 Class 2 cells 

In a class 2 cell only the values and interpretations given in table 15 shall apply. 

Table 15: Encryption mode element in class 2 cell contents 



Information element 


Length 


Value 


Remark 


Encryption mode element 


2 


OO2 


PDU not encrypted 


OI2 


Reserved 


IO2 


PDU encrypted, SCK-VN is even 


II2 


PDU encrypted, SCK-VN is odd 



To prevent attacking by replaying a previous key, the SCK shall be identified by a longer SCK-VN which shall be sent 
to an MS together with the SCK. 

NOTE: During a key changeover there may be a period when keys are different on different cells. 

6.5.1.3 Class 3 cells 

In a class 3 cell the following values and interpretations shall apply. 

Table 16: Encryption mode element in class 3 cell contents 



Information element 


Length 


Value 


Remark 


Encryption mode element 


2 


OO2 


PDU not encrypted 


OI2 


Reserved 


IO2 


PDU encrypted, CCK-id is even 


II2 


PDU encrypted, CCK-id is odd 



In class 3 cells every cell in an LA shall use the same CCK and it shall be identified by a common CCK-id in all the 
cells of the LA. The SwMI may also provide a CCK that it is applicable in more than one LA. If so the CCK shall be 
identified by a common CCK-id in all these applicable LAs. CCK change shall therefore be synchronized across all 
cells in an LA, and across all LAs in which SwMI tells that the same CCK is applicable. The CCK shall be identified by 
a longer CCK-id which shall be sent to an MS together with the CCK. The CCK-id can be selected independently for 
each location area by the SwMI. When a PDU is encrypted, the least significant bit of the encryption mode element in 
the MAC header shall be equal to the least significant bit of the CCK-id for the CCK in use. 

NOTE 1 : During a key changeover there may be a period when keys are different on different cells of applicable 
LAs. 

NOTE 2: When CCK is changed the SwMI has to ensure that the MS can recognize a CCK change in the 
encryption mode element. 

6.5.2 Identification of encryption state of uplink MAC PDUs 

One bit of uplink signalling MAC PDU headers shall be reserved for air interface encryption. This shall indicate 
whether the contents of the PDU are encrypted or not. 

This bit shall take one of the following values: 

• 0= Encryption off; 

• 1= Encryption on. 

If it is desired to change the DCK in use by an MS, this shall be achieved by the authentication process; and as both BS 
and MS are involved in the process and have knowledge that it has occurred, it shall not be necessary to include a key 
identifier in the uplink header. 

The encryption mode element shall also indicate the use of the encrypted short identity mechanism described in 
clause 4.2.6 for cells of class 2 and class 3. 
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6.6 Mobility procedures 

6.6.1 General requirements 

The cell selection procedures are defined in EN 300 392-2 [2], clause 18.3.4 and shall always apply with the additional 
security criteria defined below: 

1) if the MS does not support the security class of the cell it shall not select the cell; 

2) if the MS does not support authentication as required by the cell it shall not select the cell; 

3) if moving to a new cell of different class from the current serving cell the MS may have to perform the 
location update procedure at the new cell. 

In moving from a cell of security class 3 or security class 2 to a cell of security class 1 the SwMI shall determine if the 
call can be restored. The SwMI may wish to deny call restoration in this case because the air interface security has been 
changed. 

6.6.1 .1 Additional requirements for class 3 systems 

Where scanning of adjacent cells is performed by the moving MS the MS shall gain knowledge of the CCK-id of the 
CCK in use on the adjacent cell by receiving the SYSINFO broadcast, and of the value of IV on that cell by receiving 
the SYNC and SYSINFO broadcasts. The broadcast parameters shall be made available to the MM sub-layer by MLE 
using the MLE-INFO indication primitive. 

Within an LA of security class 3 all cells shall have knowledge of the DCK in use for each ITSI operating in that LA. If 
the SwMI offers a registered area to the MS it shall ensure that all LAs have knowledge of the DCK for that MS 
operating in that registered area. 

6.6.2 Protocol description 

If the SwMI supports GCK operation the SwMI shall indicate this using the "GCK Supported" field, described in 
clause A. 8. 29a, in the Extended Service Broadcast information element, described in EN 300 392-2 [2]. This field shall 
be used to indicate to the MS when GCKs are in use or not in use by the cell. 

6.6.2.1 Negotiation of cipher parameters 

Encryption mode control is achieved by an exchange of MM PDUs at registration. The PDU exchange shall allow 
switching both from clear to encrypted mode and the reverse. 

An MS may indicate its current encryption state to its user. 

Every registration shall include cipher parameter negotiation to allow the MS to establish the security parameters 
advised in the cell broadcast. 

EN 300 392-2 [2] defines the presence of cipher parameters in the D-LOCATION UPDATE COMMAND, D- 
LOCATION UPDATE REJECT and U-LOCATION UPDATE DEMAND PDUs. The use of these parameters is 
described in this part of the EN. 

The ciphering parameters shall be used to negotiate SCICN and KSG in class 2 cells, and KSG in class 3 cells using the 
cipher parameters element defined in table A.46. 

Table 17: Void 

If a cell supports class 2 and class 1, or class 3 and class 1, negotiation of cipher parameters by the MS shall be at the 
highest security class possible for the MS. 

NOTE: When registering for SC3 operation, the Cipher Parameters element is also used by the MS to indicate its 
support for TM-SCK OTAR, SDMO and DM-SCK OTAR, and GCK encryption/OTAR 
(see clause 6.2.0.2). 
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6.6.2.1.1 Class 1 cells 

Cipher control shall always be set to false and the ciphering parameters shall not be provided. 

6.6.2.1.2 Class 2 cells 

Cipher control shall always be set to true and the ciphering parameters shall be provided. 

On registration the MS shall declare its preferred KSG and SCKN (broadcast by the cell) to the SwMI. If these 
parameters are accepted by the SwMI the registration shall continue as described in EN 300 392-2 [2], clause 16. If the 
parameters are unacceptable the SwMI shall reject the registration and shall indicate the preferred parameters in the 
D-LOCATION UPDATE REJECT PDU. 

6.6.2.1.3 Class 3 cells 

Cipher control shall always be set to true and the ciphering parameters shall be provided. 

On registration the MS shall declare its preferred KSG to the SwMI. If these parameters are accepted by the SwMI the 
registration shall continue as described in EN 300 392-2 [2], clause 16. If the parameters are unacceptable the SwMI 
shall reject the registration and shall indicate the preferred parameters in the D-LOCATION UPDATE REJECT PDU. 

6.6.2.2 Initial and undeclared cell re-selection 

See also EN 300 392-2 [2], clause 18.3.4.7.2. 

In cells of security class 2 the MS may, if required, register and authenticate to the new cell. 

In cells of security class 3 the MS may register and authenticate to the new cell and in so doing receive new values of 
DCK and CCK. If when camped on the cell the MS confirms that it holds a valid CCK for the cell (from capturing the 
CCK-id in SYSINFO) it may not refresh the CCK during registration. 

NOTE: The broadcast parameters are available to MM from the MLE-INFO indication primitive. 

For initial cell selection (power on) in the home network, the MS may only apply AI encryption if the SwMI indicates it 
supports "DCK retrieval during initial cell selection" (DCK retrieval), shown in table A. 104, and the MS possesses a 
valid DCK and a valid CCK for the LA of the cell. A valid DCK is defined as the DCK that was last derived between 
the MS and the home SwMI. 

For initial cell selection (power on) in a visited network, the MS shall assume that the DCK generated in the previous 
network is no longer valid. Therefore, the MS shall not apply AI encryption independent of the indication by the SwMI 
to support "DCK retrieval during initial cell selection" (DCK retrieval), shown in table A. 104. 

When the MS has successfully invoked initial cell selection with the SwMI but suffers momentary radio link failure, the 
MS may use "roaming location updating" when the radio link is re-established, in which case the MS may only apply 
AI encryption if the SwMI indicates it supports "DCK retrieval during cell re-selection" (DCK retrieval), shown in 
table A. 104, and the MS possesses a valid DCK and a valid CCK for the LA of the cell. A valid DCK is defined as the 
DCK that was last derived between the MS and the SwMI. 

When the SwMI supports DCK retrieval during cell re-selection, if it possesses a valid CCK for the LA of the new cell 
the MS shall not use U-OTAR PREPARE and may apply AI encryption to location update signalling on the new cell. 

When the SwMI supports DCK retrieval during cell re-selection and the MS does not possess a valid CCK for the LA of 
the new cell, the MS shall request the CCK of the new cell using U-OTAR PREPARE before selection of the new cell, 
and may apply AI encryption to location update signalling on the new cell. 

If the SwMI does not support DCK retrieval during cell re-selection, and if the MS knows the preferred neighbour cell, 
the MS may use the U-OTAR PREPARE PDU indicating the LA of the new cell where the PDU is sent on the MCCH 
and shall start timer T372. On receipt of U-OTAR PREPARE, the SwMI shall forward the DCK belonging to the MS to 
the cells belonging to the LA (DCK forwarding), if possible. The MS shall reset timer T372 on receipt of D-OTAR 
NEWCELL. Following this, the MS may apply AI encryption to location update signalling on the new cell if the DCK 
forwarding was successful and it possesses a valid CCK for the LA of the new cell. This procedure is shown in 
figure 54 where the LA-id of the new cell is known to the MS. The MS may request the CCK of the new cell using 
U-OTAR PREPARE if it does not already have it. 
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Figure 54: Use of U-OTAR PREPARE and D-OTAR NEWCELL protocol 

If the MS does not know a preferred neighbour cell, it cannot indicate the preferred neighbour cell to the SwMI and 
therefore the SwMI cannot forward the DCK to the new cell. On successful completion of cell re-selection, and if 
forwarding of the DCK failed or was not possible (due to radio link failure), the MS may only apply AI encryption to 
location updating if the SwMI indicates it supports "DCK retrieval during cell re-selection" (referred to herein as DCK 
retrieval), shown in table A. 104, and the MS possesses a valid CCK for the LA of the new cell. 

6.6.2.3 Unannounced cell re-selection 

See also EN 300 392-2 [2], clause 18.3.4.7.3. 

In cells of security class 2 the MS may register and if required authenticate to the new cell. 

After successful registration and restoration of security parameters any calls in progress may be restored. 
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In cells of security class 3 the MS may register and authenticate to the new cell and in so doing receive new values of 
DCK and CCK. 

When the SwMI supports DCK retrieval during cell re-selection, the MS shall not use U-OTAR PREPARE and may 
apply AI encryption to location update signalling on the new cell if it possesses a valid CCK for the LA of the new cell. 
However, if the SwMI does not support DCK retrieval during cell re-selection, and if the MS knows the preferred 
neighbour cell it should indicate the LA of the new cell using the U-OTAR PREPARE PDU sent on the MCCH and 
shall start timer T372. When the SwMI receives this signalling it shall forward the DCK belonging to the MS to the 
cells belonging to the LA (DCK forwarding) if possible. The MS shall reset timer T372 on receipt of D-OTAR 
NEWCELL. Following this, the MS may apply AI encryption to location update signalling on the new cell if the DCK 
forwarding was successful and it possesses a valid CCK for the LA of the new cell. 

If the MS does not know a preferred neighbour cell it cannot indicate the preferred neighbour cell to the SwMI and 
therefore the SwMI cannot forward the DCK to the new cell. On successful completion of cell re-selection, the MS may 
only apply AI encryption if the SwMI indicates it supports "DCK retrieval during cell re-selection" (DCK retrieval), 
shown in table A. 104, and the MS possesses a valid CCK for the LA of the new cell. 

6.6.2.4 Announced cell re-selection type-3 

See also EN 300 392-2 [2], clause 18.3.4.7.4. 

When the SwMI supports DCK retrieval during cell re-selection, the MS shall not use U-OTAR PREPARE and may 
apply AI encryption to location update signalling on the new cell if it possesses a valid CCK for the LA of the new cell. 
However, if the SwMI does not support DCK retrieval during cell re-selection, and if the MS knows the preferred 
neighbour cell it should indicate the LA of the new cell using the U-OTAR PREPARE PDU and shall start timer T372. 
When the SwMI receives this signalling it shall forward the DCK belonging to the MS to the cells belonging to the LA 
(DCK forwarding) if possible. The MS shall reset timer T372 on receipt of D-OTAR NEWCELL. Following this, the 
MS may apply AI encryption to location update signalling on the new cell if the DCK forwarding was successful and it 
possesses a valid CCK for the LA of the new cell. 

6.6.2.5 Announced cell re-selection type-2 

See also EN 300 392-2 [2], clause 18.3.4.7.5. 

The SwMI shall use the cell identifier in the U-PREPARE to forward the DCK to the new cell (DCK forwarding). On 
successful completion of cell re-selection, the MS may apply AI encryption on the new cell if it possesses a valid CCK 
for the location area of the new cell. If the MS does not possess a valid CCK for the new cell it should request it before 
selection of the new cell. 

6.6.2.6 Announced cell re-selection type-1 

See also EN 300 392-2 [2], clause 18.3.4.7.6. 

The SwMI shall use the cell identifier in the U-PREPARE to forward the DCK to the new cell (DCK forwarding). On 
successful completion of cell re-selection, the MS may apply AI encryption on the new cell if it possesses a valid CCK 
for the location area of the new cell. If the MS does not possess a valid CCK for the new cell it shall request it before 
selection of the new cell. 

6.6.2.7 Key forwarding 

When the SwMI does not support DCK retrieval during cell re-selection, the U-OTAR PREPARE / D-OTAR 
NEWCELL signalling is used for forwarding the DCK to the new LA and requesting the associated CCK. No other 
mobility management or call restoration functionality shall be assumed by the SwMI or the MS. 

Timer T372, Key Forwarding Timer, shall have a value of 5 seconds. 

T372 shall indicate the maximum time the MM shall wait for a response to U-OTAR PREPARE. If timer T372 expires, 
or radio link failure occurs, the MS shall abandon signalling and initiate the cell change procedure immediately 
(see figure 55). 
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Figure 55: Use of U-OTAR PREPARE and D-OTAR NEWCELL protocol with T372 expiry 
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6.7 Encryption control 

The following clauses apply for class 2 and class 3 cells. 

6.7.1 Data to be encrypted 

6.7.1 .1 Downlink control channel requirements 

The following control messages shall not be encrypted on the downlink, as they may be used by MSs prior to 
establishment of encryption parameters: 

• cell synchronization messages sent to the MAC via the TMB-SAP (SYNC, SYSINFO); and 

• the ACCESS DEFINE PDU is not encrypted as it has no associated TM-SDU. 

6.7.1 .2 Encryption of MAC header elements 

When encryption is enabled some of the MAC header shall be considered by the encryption unit as belonging to the 
TM-SDU. The following rules apply when the encryption is on: 

• in the MAC-RESOURCE PDU (see EN 300 392-2 [2], clause 21.4.3.1) all information following the channel 
allocation flag shall be encrypted. The channel allocation flag shall not be included in the data to be encrypted; 

• in the downlink MAC -END PDU (see EN 300 392-2 [2], clause 21 .4.3.3) all information following the 
channel allocation flag shall be encrypted. The channel allocation flag shall not be included in the data to be 
encrypted. 

The encryption process shall be accomplished in the same manner as is used to encrypt TM-SDUs, i.e. the modulo 2 
addition of a key stream, where the key stream shall be generated as a function of frame numbering and cipher key 
relevant to the addressed party or parties. 

The KSG shall be initialized as described in clause 6.3.2.1. 

6.7.1 .3 Traffic channel encryption control 

Traffic channels may be transporting speech or data. The information shall be encrypted prior to channel encoding. 

Traffic slots do not incorporate a separate MAC header in the same way as control (signalling) slots. Instead, the entire 
slot is used for traffic data. Therefore on a traffic slot, the SDU that is encrypted is the entire content of the transmitted 
slot. 

The initial use of encryption on the U-PLANE shall maintain the use of encryption of the C-PLANE signalling message 
which contains the channel allocation element. 

The MAC-RESOURCE PDU indicates the encryption state of the PDU and when the PDU contains a channel 
allocation element the encryption state of the assigned channel shall follow the state of MAC RESOURCE PDU 
(see EN 300 392-2 [2], clause 21.4.3.1) and the "Encryption mode element" as defined in clause 6.5.1. Encryption of 
control and traffic (speech/data) channels shall be switched on and off only by the SwMI. For the duration of the 
channel allocation the encryption state shall not change, however change of parameters within the encryption state may 
be allowed. 

In the case that U-PLANE mode is "encrypted" the MS shall send all signalling encrypted (sent with one of stealing. 
Fast Associated Control Channel (FACCH), Slow Associated Control Channel (SACCH)). In the case where U-PLANE 
mode of an assigned channel for a call is "clear" the MS shall send all signalling related to that call in clear (sent with 
one of stealing, FACCH, SACCH) and other signalling may be encrypted. 

U-PLANE signalling (using STCH) is encrypted starting from the first bit of TM-SDU (see EN 300 392-2 [2], 
clause 21.4.5). In this case the MAC header does not contain the encryption flag, hence encryption parameters shall be 
the same as for the traffic. 
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6.7.1.4 



Handling of PDUs that do not conform to negotiated ciphering mode 



The SwMI is not required to send a layer 2 or layer 3 response to PDUs received from an MS with a ciphering mode 
differing from the ciphering mode negotiated with that MS. 

The MS is not required to send a layer 2 or layer 3 response to PDUs received from the SwMI with a ciphering mode 
differing from the ciphering mode negotiated with that SwMI. 

6.7.2 Service description and primitives 

Each layer in the protocol stack provides a set of services to the layer above. This clause describes the services that are 
added to those provided by each layer due to the incorporation of encryption, in addition to those specified in 
EN 300 392-2 [2]. The primitives that are passed between the layers are also described. 

The primitives required to control encryption are summarized in figure 56. 



TNMM-REGISTRATION confirm 
Encryption_control, KSG_number 



TNMM-REGISTRATION request 
Encryption_control 



TNMM-REGISTRATION indication 
Encryption_control, KSG_number 



TNMM-SAP 



MLE-ENGRYPTION confirm 
Key_cliange 



MLE-ENGRYPTION request 
Key_download_type 
Optional-parameters 



MLE-ENGRYPTION indication 
Gell_security_class 
Conditional-parameters 
Optional-parameters 

MLE-INFO indication 
Broadcast parameters 



LMM-SAP 



TL-ENGRYPTION confirm 
Key_cliange 



TL-ENGRYPTION request 
Key_download_type 
Optional-parameters 



TL-ENGRYPTION indication 
Gell_security_class 
Conditional-parameters 
Optional-parameters 



TLG-SAP 



Figure 56: Protocol stack and primitives for encryption control 
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6.7.2.1 



Mobility Management (MM) 



TNMM SAP: the encryption control procedure shall only be invoked by the SwMI using the registration procedure. The 
MS-MM may indicate its current state, or a change of state, to the MS application. 

The primitive TNMM-REGISTRATION shall contain the parameter "Encryption control" to enable/disable the 
encryption process, and the parameter "KSG number". 

Table 18: TNMM-REGISTRATION parameters (c.f. EN 300 392-2 [2], clause 15.3.3.7) 



Parameter 


Request 


Indication 


Confirm 


Registration Status 


- 


M 


M 


Registration Reject Cause (see note 1) 


- 


C 


- 


Registration Type 


M 


- 


- 


Location Area (see note 2) 


C 


- 


- 


IVICC (see note 3) 


C 


- 


- 


IVINC (see note 3) 


C 


- 


- 


ISSI or ASSI or USSI (see note 4) 


M 


- 


- 


Group identities 


- 








Group identity request 





- 


- 


Group identity attach/detach mode 











Group identity report 





- 


- 


Encryption control 


M 


M 


M 


KSG number 


- 








Key: IVI = IVIandatory; C = Conditional; = Optional 

NOTE 1 : Shall be present if Registration Status = "failure". 

NOTE 2: Shall be present if Registration Type = "No new ITSI - forward registration". 

NOTE 3: Shall be present if Registration Type = "New ITSI" or 

Registration Type = "No new ITSI - forward registration". 
NOTE 4: A previously established and valid ASSI may be used to prevent exposure of the 

ITSI at registration. 



6.7.2.2 Mobile Link Entity (MLE) 

At the LMM SAP the following MLE services shall be provided to MM: 

• loading of keys; 

• start and stop ciphering. 

These services shall be achieved by passing information to the MAC layer using the MLE-ENCRYPTION request 
primitive. The MAC shall indicate to MM the current CCK-id that is received in the broadcast SYSINFO PDU. 

The MAC shall indicate to MM if the short CCK-id or short SCK-VN (in the MAC RESOURCE PDU) does not 
correspond to the CCK identifier or SCK-VN of the CCK or SCK that MLE is currently using. In addition the MAC 
shall indicate to MM if the encryption information received in SYSINFO has changed. 
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Table 19: MLE-ENCRYPTION parameters 



Parameter 


Request 


Confirm 


Indication 


Key download type 


M 




- 


KSG Number (see note 1) 







- 


SCK (see note 2) 


C 




- 


DCK (see note 2) 


C 




- 


CCK (see note 2) 


C 




- 


CCK-id (see notes 2, 4) 


C 




C 


SCK-VN 


C 




C 


SCKN 


c 




c 


MGCK (see note 2) 


c 




- 


GTSI (see note 3) 


c 




- 


xSSI (see note 5) 


c 




- 


GSKO 


c 






Cipher usage (see note 1) 







- 


Time (see note 6) 









Key change (see note 6) 


- 


M 


- 


Cell security class 






M 


Cell parameters changed 









Key: 
NOTE 1 

NOTE 2 
NOTES 
NOTE 4 
NOTES 
NOTE 6 


IVI = Mandatory; C = Conditional; = Optional 

May be omitted if the state of the parameter has not changed from the 

previous request. 

Key download type indicates which fields are present. 

Provided if MGCK downloaded. 

CCK-id supplied in indication. 

This is the SSI associated with the DCK when DCK is downloaded. 

If invoked from KEY CHANGE DEMAND. 



Key download type parameter indicates which encryption keys, if any, are downloaded to the MAC in this request. 

• Key download type = 

no keys downloaded; 
SCK, SCKN, SCK-VN; 
DCK, xSSI pair; 
CCK, CCK-id, LA-id; 
MGCK, GTSI; 
GSKO. 
KSG Number parameter indicates the Key Stream Generator (one of 16 possible) in use. 

• KSG Number = 

KSG 1; 
KSG 2 
KSG 3 



KSG 16. 



£75/ 



1 1 2 ETSI TS 1 00 392-7 V2.4.1 (2006-1 0) 

Cipher usage parameter indicates to the MAC whether the transmitted messages should be encrypted and whether the 
MAC should try to decrypt received encrypted messages. 

• Cipher usage = 

encryption off; 

RX; 

RX and TX. 

6.7.2.3 Layer 2 

The layer 2 service shall load keys and start and stop the ciphering as required by the MM/MLE request. The MAC 
shall also be responsible for applying the correct key depending on the identity placed in the header of each MAC PDU. 
This is described in EN 300 392-2 [2], clause 21. 

The corresponding MLE-ENCRYPTION request and indication should be passed through the LLC in a transparent way 
by using TL-ENCRYPTION request and indication respectively at the TLC-S AP, the boundary between the MLE and 
LLC. Similarly, the LLC should exchange the TM-ENCRYPTION request and indication at the TMC-SAP, the 
boundary between the LLC and the MAC. 

In security class 3 the MAC shall indicate to MLE/MM the CCK-id of the current CCK in use in the cell. In security 
class 2, the MAC shall indicate the SCK-VN in use. 

Encryption shall be performed in the upper MAC before EEC and interleaving. 

6.7.3 Protocol functions 

Each functional entity in the protocol stack shall communicate with its peer entity using a defined protocol; for example 
the MM entity in the MS communicates with its peer MM entity in the SwMI. The incorporation of encryption at the air 
interface requires additional functions to be added to some of the functional entities of the protocol stack. These 
functions shall be as described in the present clause. 

6.7.3.1 MM 

The protocol functions for air interface security shall be the following: 

• ciphering type elements shall be contained in the U- and D- LOCATION UPDATE PDUs. A negotiation for 
ciphering types shall be performed in a re-registration if the parameters are not acceptable; 

• MM may have to perform a re-registration if the SwMI requires a change in the encryption parameters 
including on-off control of encryption. 

6.7.3.2 MLE 

No encryption functionality shall be added to the MLE protocol. The management SAP (TLC-SAP) should be used 
inside the MS to deliver the new ciphering parameters to the MAC and to receive an indication of a change in the short 
SCK-VN (class 2) or CCK-id (class 3) from the MAC. 

6.7.3.3 LLC 

The LLC is used to control the encryption mode of BL-ACK/BL-ADATA/BL-ACKh-DATA, etc. 

No encryption functionality shall be added to the LLC protocol. The management SAP (TLC-SAP) should be used 
inside the MS to deliver the new ciphering parameters to the MAC and to receive an indication of a change in the short 
SCK-VN (class 2) or CCK-id (class 3) from the MAC. 
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6.7.3.4 MAC 



The MAC shall indicate to MM a change in the SCKVN (Class 2) or CCK-id (Class 3) broadcast in MAC SYSINFO 
using the MLE-INFO primitive. 

The MAC shall indicate to MM a change of security class broadcast in MAC SYSINFO using the MLE-INFO 
primitive. 

6.7.4 PDUs for cipher negotiation 

Ciphering elements shall be contained in the U-LOCATION UPDATE DEMAND, D-LOCATION UPDATE 
COMMAND, and the D-LOCATION UPDATE REJECT PDUs to permit negotiation of encryption parameters. These 
PDUs are described in EN 300 392-2 [2], clause 16.9. 

The definition of reject cause is given in EN 300 392-2 [2], clause 16.10.42. 

The MS-MM may suggest initial encryption parameters in the U-LOCATION UPDATE DEMAND PDU. The MS-MM 
shall assume that these parameters are acceptable and inform the MAC to use these parameters with the MLE- 
Encryption primitive. If the parameters are not acceptable the BS-MM shall reject them using the D-LOCATION 
UPDATE REJECT with reject cause set to one of: 

no cipher KSG; 

identified cipher KSG not available; 

requested cipher key type not available; 

identified cipher key not available; 

ciphering required. 

If the encryption parameters are rejected the MS-MM shall use MLE-ENCRYPTION to inform the MAC to modify the 
parameters in accordance with the D-LOCATION UPDATE REJECT cause. 

If the reject cause is "ciphering required" the MS may choose a set of parameters and send a new U-LOCATION 
UPDATE DEMAND or it may initiate the authentication process using the U- AUTHENTIC ATE DEMAND exchange 
described in clause 4.4.7. 

NOTE: If the MS cannot negotiate compatible cipher parameters it should consider rejection, with one of these 

causes, to be rejection from the cell and not rejection from the complete SwMI. The MS may attempt cell 
reselection to find another cell where its security parameters may be acceptable. 
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Annex A (normative): 

PDU and element definitions 



The PDUs detailed within this annex shall be visible at the Um reference point (see EN 300 392-1 [1], clause 5). 
The general format and encoding rules are defined for all MM PDUs in EN 300 392-2 [2], clause 14.7. 

A.1 Authentication PDUs 

A.1 .1 D- AUTHENTICATION demand 

Shall be used by the infrastructure to initiate an authentication of the MS. 

• Direction: SwMI to MS; 

• Service used: MM; 

• Response to: U-LOCATION UPDATE DEMAND or none; 

• Response expected: U-AUTHENTICATION RESPONSE. 

Table A.1 : D-AUTHENTICATION DEMAND PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


D-AUTHENTICATION 


Authentication sub-type 


2 


1 


M 


DEMAND 


Random cliallenge [RAND1] 


80 


1 


M 




Random seed [RS] 


80 


1 


M 




Proprietary element 




3 








A.1 .2 D-AUTHENTICATION reject 

Shall be used by the infrastructure to report to the MS any rejection of an authentication demand. 

• Direction: SwMI to MS; 

• Service used: MM; 

• Response to: U-AUTHENTICATION DEMAND or U-LOCATION UPDATE DEMAND 

containing RAND2; 

• Response expected: none. 

Table A.2: D-AUTHENTICATION REJECT PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


D-AUTHENTICATION 


Authentication sub-type 


2 


1 


M 


REJECT 


Authentication reject reason 


3 


1 


M 
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A.1 .3 D-AUTHENTICATION response 

Shall be used by the infrastructure to respond to an authentication demand from the MS. 

• Direction: SwMI to MS; 

• Service used: MM; 

• Response to: U-AUTHENTICATION DEMAND; 

• Response expected: U-AUTHENTICATION RESULT. 

Table A.3: D-AUTHENTICATION RESPONSE PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 




M 


D-AUTHENTICATION 


Authentication sub-type 


2 




M 


RESPONSE 


Random seed [RS] 


80 




M 




Response value [RES2] 


32 




M 




IVIutual authentication flag 


1 




M 




Random challenge [RAND1] 


80 




C 


See note 


Proprietary element 




3 







NOTE: RAND1 is conditional on the Mutual authentication flag element. RAND1 shall be present if IVIutual 
authentication flag = 1 . Otherwise, RAND1 shall not be present in the PDU. 



A.1 .4 D-AUTHENTICATION result 

Shall be used by the infrastructure to report the result of an MS authentication to the MS. 

• Direction: SwMI to MS; 

• Service used: MM; 

• Response to: U-AUTHENTICATION RESPONSE or U-AUTHENTICATION RESULT; 

• Response expected: U-AUTHENTICATION RESULT or none. 

Table A.4: D-AUTHENTICATION RESULT PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


D-AUTHENTICATION 


Authentication sub-type 


2 


1 


M 


RESULT 


Authentication result [R1] 


1 


1 


M 




Mutual authentication flag 


1 


1 


M 




Response Value [RES2] 


32 




C 


See note 


Proprietary element 




3 







NOTE: RES2 is conditional on the Mutual authentication flag element. RES2 shall be present if Mutual 
authentication flag = 1 . Otherwise, RES2 shall not be present in the PDU. 



A.1 .5 U-AUTHENTICATION demand 

Shall be used by the MS to initiate an authentication of the BS/SwMI. 

• Direction: MS to SwMI; 

• Service used: MM; 

• Response to: none; 

• Response expected: D-AUTHENTICATION RESPONSE or none. 
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Table A.5: U-AUTHENTICATION DEMAND PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


U-AUTHENTICATION 


Authentication sub-type 


2 


1 


M 


DEMAND 


Random challenge [RAND2] 


80 


1 


M 




Proprietary element 




3 








A.1 .6 U-AUTHENTICATION reject 



Shall be used by the MS to report to the infrastructure rejection of an authentication demand which does not occur 
within the ENABLE/DISABLE protocol. 

• Direction: MS to SwMI; 

• Service used: MM; 

• Response to: D-AUTHENTICATION DEMAND; 

• Response expected: none. 

Table A.6: U-AUTHENTICATION REJECT PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


U-AUTHENTICATION 


Authentication sub-type 


2 


1 


M 


REJECT 


Authentication reject reason 


3 


1 


M 





A.1 .7 U-AUTHENTICATION response 

Shall be used by MS-MM to respond to an authentication demand from the SwMI of the MS. 

• Direction: MS to SwMI; 

• Service used: MM; 

• Response to: D-AUTHENTICATION DEMAND or D-ENABLE or D-DISABLE; 

• Response expected: D-AUTHENTICATION RESULT. 

Table A.7: U-AUTHENTICATION RESPONSE PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


U-AUTHENTICATION 


Authentication sub-type 


2 


1 


M 


RESPONSE 


Response Value [RES1] 


32 


1 


M 




Mutual authentication flag 


1 


1 


M 




Random challenge [RAND2] 


80 




C 


See note 


Proprietary element 




3 







NOTE: RAND2 is conditional on the Mutual authentication flag element. RAND2 shall be present if Mutual 
authentication flag = 1 . Otherwise, RAND2 shall not be present in the PDU. 
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A.1 .8 U-AUTHENTICATION result 

Shall be used by MS-MM to report the result of an authentication of the BS/SwMI. 

• Direction: MS to SwMI; 

• Service used: MM; 

• Response to: D-AUTHENTICATION RESULT or D-AUTHENTICATION RESPONSE; 

• Response expected: D-AUTHENTICATION RESULT or none. 

Table A.8: U-AUTHENTICATION RESULT PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


U-AUTHENTICATION 


Authentication sub-type 


2 


1 


M 


RESULT 


Autlientication result [R2] 


1 


1 


M 




IVIutual authentication flag 


1 


1 


M 




Response Value [RES1] 


32 




C 


See note 


Proprietary element 




3 







NOTE: RES1 is conditional on the Mutual authentication flag element. RES1 shall be present if Mutual 
authentication flag = 1 . Otherwise, RES1 shall not be present in the PDU. 



A.2 OTAR PDUs 

A.2. 1 D-OTAR CCK Provide 

Shall be used by the infrastructure to provide CCK to an MS. 

• Direction: SwMI to MS; 

• Service used: MM; 

• Response to: U-OTAR CCK Demand or none; 

• Response expected: U-OTAR CCK Result or none. 

Table A.9: D-OTAR CCK Provide PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


D-OTAR 


OTAR sub-type 


4 


1 


M 


CCK Provide 


CCK provision flag 


1 


1 


M 




CCK information 


Varies 




C 


If CCK provision flag is true 


Proprietary element 




3 








A.2.2 U-OTAR CCK Demand 

Shall be used by MS-MM to request CCK for a location area from the SwMI. 

• Direction: MS to SwMI; 

• Service used: MM; 

• Response to: none; 

• Response expected: D-OTAR CCK Provide. 
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Table A.10: U-OTAR CCK Demand PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


U-OTAR 


OTAR sub-type 


4 


1 


M 


CCK Demand 


Location Area 


14 


1 


M 




Proprietary element 




3 








A.2.3 U-OTAR CCK Result 



Shall be used by MS-MM to explicitly accept or reject some or all of the CCKs provided by the SwMI. 
• Direction: MS to SwMI; 



• Service used: 

• Response to: 



MM; 

D-OTAR CCK Provide or D-LOCATION UPDATE ACCEPT containing CCK 

Information; 



Response expected: none. 



Table A.11 : U-OTAR CCK Result PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


U-OTAR 


OTAR sub-type 


4 


1 


M 


CCK Result 


Provision result 


3 


1 


M 


Provision result for CCK 


Future key flag 


1 


1 


M 




Provision result (Future key) 


3 




C 


If future key flag is true (see note) 


Proprietary element 




3 







NOTE: If D-OTAR CCK Provide or D-LOCATION UPDATE ACCEPT gives both current and future CCK then this 
flag is set true and this PDU shall contain two provision result fields. If D-OTAR CCK Provide PDU or 
D-LOCATION UPDATE ACCEPT provides only a future CCK then this flag shall be false. 



A.2.4 D-OTAR GCK Provide 

Shall be used by the infrastructure to provide GCK to an MS. 

• Direction: SwMI to MS; 

• Service used: MM; 

• Response to: U-OTAR GCK Demand or none; 

• Response expected: U-OTAR GCK Result. 
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Table A.12: D-OTAR GCK Provide PDU contents 



Information element 


Length) 


Type 


C/O/IM 


Remark 


PDU type 


4 


1 


M 


D-OTAR 


OTAR sub-type 


4 


1 


M 


GCK Provide. 


Acknowledgement flag 


1 


1 


M 


If "0" No acknowledgement required 


If "1" Acknowledgement required 


Reserved 


1 




C 


Provided if Acknowledgement flag set to "0" 


Explicit response (see note 1) 


1 




C 


Provided if Acknowledgement flag set to "1" 


Max response timer value 


16 


1 


M 


Identifies the maximum period of timer T371 
over which the MS will randomly choose to 
respond 


Session key 


1 


1 


M 


Identifies if encrypted with group or individual 
encryption session key 


Random Seed for OTAR 


80 




C 


Provided if session key for individual 


GSKO-VN 


16 




C 


Provided if session key for group 


Number of GCKs provided 


3 




M 


See note 2 


GCK key and identifier 


152 




C 


See note 3 


KSG number 


4 


1 


M 


Associates GCK to a particular encryption 
algorithm 


Group association 


1 


1 


M 




GSSI 


24 




C 


If Group association = GSSI 


OTAR retry interval 


3 


1 


M 


See note 4 


Address extension 


24 


2 





See note 5 


Proprietary element 




3 







NOTE 1 : If the "explicit response" element = 1 , the MS shall respond whether the key provide changes the MS state 
or not; if "explicit response" = 0, the MS shall only respond if the SwMI provides a key or key version that 
the MS did not previously have. The "explicit response" element is only valid if "Acknowledgment field" is 
set to "1 "the "explicit response" element = 1 , the MS shall respond whether the key provide changes the 
MS state or not; if "explicit response" = 0, the MS shall only respond if the SwMI provides a key or key 
version that the MS did not previously have. 

NOTE 2: The number of GCKs provided may not be the same as the number of GCKs originally requested. 

NOTE 3: This element is repeated according to "Number of GCKs provided" value. If "Number of GCKs 
provided" = 0, there shall be no "GCK key and identifier" elements in the PDU. 

NOTE 4: Where group association indicates GSSI the provided GCKs shall all have the GCKN associated with the 
indicated GSSI and shall have different GCK-VNs. 

NOTE 5: The address extension element shall be present only if the network code for which the provided GCK 
relates is different to the serving network. 



A.2.5 U-OTAR GCK Demand 

Shall be used by the MS to request GCKs from the SwMI. 

• Direction: MS to SwMI; 

• Service used: MM; 

• Response to: none; 

• Response expected: D-OTAR GCK Provide 
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Table A.I 3: U-OTAR GCK Demand PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


U-OTAR 


OTAR sub-type 


4 


1 


M 


GCK Demand 


KSG number 


4 


1 


M 


Associates GCK with a particular 
encryption algorithm 


Number of GCKs requested by GCKN 


3 


1 


M 


(See note 1 ) 


GGKN 


16 







Shall be repeated the number of times 
indicated by the "Number of GCKs 
requested by GCKN" information 
element 


Number of GCKs requested by GSSl 


3 


1 


M 


(See note 1) 


GSSI 


24 







Shall be repeated the number of times 
indicated by the "Number of GCKs 
requested by GSSI" information 
element 


Address Extension 


24 


2 





See note 2 


Proprietary element 




3 







NOTE 1 : The total number of GCKs requested in this PDU (i.e. the sum of these elements) shall not be zero 

and shall not exceed seven. 
NOTE 2: The address extension element shall be present only if the network code for which the requested 

GCK relates is different to the serving network. 



A.2.6 U-OTAR GCK Result 

Shall be used by MS-MM to explicitly accept or reject a GCK provided by the SwMI. 

• Direction: MS to SwMI; 

• Service used: MM; 

• Response to: D-OTAR GCK Provide; 

• Response expected: none. 

Table A.14: U-OTAR GCK Result PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


U-OTAR 


OTAR sub-type 


4 


1 


M 


GCK Result 


Number of GCKs provided 


3 


1 


M 




GCK provision result 


Varies 




C 


Repeated according to Number of GCKs 
provided value 


Address Extension 


24 


2 





See note 


Proprietary element 




3 







NOTE: The address extension element shall be present only if the network code for which the provided GCK 
relates is different to the serving network. 



A.2.6a D-OTAR GCK Reject 

Shall be used by the infrastructure to explicitly reject GCK requests from an MS. 

• Direction: SwMI to MS; 

• Service used: MM; 

• Response to: U-OTAR GCK Demand. 
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Table A.15: D-OTAR GCK Reject PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 


D-OTAR 


OTAR sub-type 


4 


1 


M 


GCK Reject 


Number of GCKs rejected 


3 


1 


M 




GCK rejected 


Varies 




C 


See note 1 


OTAR Retry Interval 


3 


1 


M 




Address Extension 


24 


2 





See note 2 


Proprietary element 




3 







NOTE 1 : This element is repeated according to the "Number of GCKs rejected" value. 

NOTE 2: The address extension element shall be present only if the network code for which the provided GCK 
relates is different to the serving network. 



A.2.7 D-OTAR SCK Provide 

Shall be used by the infrastructure to provide SCK to an MS. 
• Direction: SwMI to MS; 



Service used: 



MM; 



• Response to: U-OTAR SCK Demand or none; 

• Response expected: U-OTAR SCK Result. 



Table A.16: D-OTAR SCK Provide PDU contents 



Information element 


Length) 


Type 


C/O/IM 


Remark 


PDU Type 


4 


1 


M 


D-OTAR 


OTAR sub-type 


4 


1 


M 


SCK Provide 


Acknowledgement flag 


1 


1 


M 


If "0" No acknowledgement required 










If "1" Acknowledgement required 


Reserved 


1 




C 


Provided if Acknowledgement flag set to "0" 


Explicit response (see note 1) 


1 




C 


Provided if Acknowledgement flag set to "1" 


IVIax response timer value 


16 


1 


M 


Identifies the maximum period over which the 
MS will randomly choose to respond 


Session key 


1 


1 


M 


Identifies if encrypted with group or individual 
encryption session key 


Random seed for OTAR 


80 




C 


Provided if session key for individual 


GSKO-VN 


16 




C 


Provided if session key for group 


Number of SCKs provided 


3 


1 


M 


See note 2 


SCK key and identifier 


143 




C 


See note 3 


KSG number 


4 


1 


M 


Associates SCK with a particular encryption 
algorithm 


OTAR Retry Interval 


3 


1 


M 




Address Extension 


24 


2 





See note 4 


Proprietary element 




3 







NOTE 1 : If the "explicit response" element = 1 , the MS shall respond whether the key provide changes the MS state 

or not; if "explicit response" = 0, the MS shall only respond if the SwMI provides a key or key version that 

the MS did not previously have. 
NOTE 2: The number of SCKs provided may not be the same as the number of SCKs originally requested. 
NOTE 3: This element is repeated according to "Number of SCKs provided" value. If "Number of SCKs 

provided" = 0, there shall be no "SCK key and identifier" elements in the PDU. 
NOTE 4: The address extension element shall be present only if the network code for which the provided SCK 

relates is different to the serving network. 
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A.2.8 U-OTAR SCK Demand 

Shall be used by the MS to request SCK from the SwMI. 
• Direction: MS to SwMI; 



Service used: 



MM; 



Response to: none; 

Response expected: D-OTAR SCK Provide. 



Table A.I 7: U-OTAR SCK Demand PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


U-OTAR 


OTAR sub-type 


4 


1 


M 


SCK Demand 


KSG number 


4 


1 


M 


Associates SCK with a particular encryption 
algorithm 


Number of SCKs requested 


3 


1 


M 




SCK number (SCKN) 


5 




C 


See note 1 


Address Extension 


24 


2 





See note 2 


Proprietary element 




3 







NOTE 1 : This element is repeated according to the "Number of SCKs element, requested" value. 
NOTE 2: The address extension element shall be present only if the networl< code for which the requested SCK 
relates is different to the serving network. 



A.2.9 U-OTAR SCK Result 



Shall be used by MS-MM to explicitly accept or reject the SCKs provided by the SwMI. 

• Direction: MS to SwMI; 

• Service used: MM; 

• Response to: D-OTAR SCK Provide or D-LOCATION UPDATE ACCEPT containing 

SCK Information; 

• Response expected: none. 

Table A.I 8: U-OTAR SCK Result PDU contents 



Information element 


Length! 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


U-OTAR 


OTAR sub-type 


4 


1 


M 


SCK Result 


Number of SCKs provided 


3 


1 


M 




SCK number and result 


Varies 




C 


See note 1 


Address Extension 


24 


2 





See note 2 


Proprietary element 




3 







NOTE 1 : This element is repeated according to the "Number of SCKs provided" value. 

NOTE 2: The address extension element shall be present only if the network code for which the requested SCK 
relates is different to the serving network. 
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A.2.9a D-OTAR SCK Reject 



Shall be used by the infrastructure to reject provision of SCK to an MS. 

• Direction: SwMI to MS; 

• Service used: MM; 

• Response to: U-OTAR SCK Demand; 

• Response expected: none. 

Table A.19: D-OTAR SCK Reject PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


D-OTAR 


OTAR sub-type 


4 


1 


M 


SCK Reject 


Number of SCKs rejected 


3 


1 


M 




SCK rejected 


8 




C 


See note 1 


OTAR Retry Interval 


3 


1 


M 




Address Extension 


24 


2 





See note 2 


Proprietary element 




3 







NOTE 1 : This element is repeated according to the "Number of SCKs rejected" value. Each rejected SCK shall be 

associated with its own OTAR reject reason. 
NOTE 2: The address extension element shall be present only if the network code for which the requested SCK 

relates is different to the serving network. 



A.2.10 D-OTAR GSKO Provide 

Shall be used by the infrastructure to provide GSKO and CMG GTSI to an MS. 

• Direction: SwMI to MS; 

• Service used: MM; 

• Response to: U-OTAR GSKO Demand or none; 

• Response expected: U-OTAR GSKO Result. 

Table A.20: D-OTAR GSKO Provide PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 




M 


D-OTAR 


OTAR sub-type 


4 




M 


GSKO Provide 


Random seed for OTAR 


80 




M 




GSKO-VN 


16 




M 




Sealed GSKO 


120 




M 




GSSI 


24 




M 




Address extension (see note) 


24 


2 







Proprietary element 




3 







NOTE: The address extension element shall be present only if the network code for which the provided GSKO 
relates is different to the serving network. 
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A.2.1 1 U-OTAR GSKO Demand 

Shall be used by the MS to request GSKO from the SwMI. 

• Direction: MS to SwMI; 

• Service used: MM; 

• Response to: none; 

• Response expected: D-OTAR GSKO Provide. 

Table A.21 : U-OTAR GSKO Demand PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


U-OTAR 


OTAR sub-type 


4 


1 


M 


GSKO Demand 


Address extension (see note) 


24 


2 







Proprietary element 




3 







NOTE: The address extension element shall be present only if the network code for which the requested GSKO 
relates is different to the serving network. 



A.2.1 2 U-OTAR GSKO Result 



Shall be used by MS-MM to explicitly accept or reject the GSKO and CMG GTSI provided by the SwMI. 

• Direction: MS to SwMI; 

• Service used: MM; 

• Response to: D-OTAR GSKO Provide; 

• Response expected: none. 

Table A.22: U-OTAR GSKO Result PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 




M 


U-OTAR 


OTAR sub-type 


4 




M 


GSKO Result 


GSKO-VN 


16 




M 




Provision result 


3 




M 




GSSI 


24 




M 




Address extension (see note) 


24 


2 







Proprietary element 




3 







NOTE: The address extension element shall be present only if the network code for which the provided GSKO 
relates is different to the serving network. 



A.2.1 2a D-OTAR GSKO Reject 

Shall be used by the infrastructure to reject provision of GSKO to an MS. 

• Direction: SwMI to MS; 

• Service used: MM; 

• Response to: U-OTAR GSKO Demand; 

• Response expected: none. 
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Table A.23: D-OTAR GSKO Reject PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 




M 


D-OTAR 


OTAR sub-type 


4 




M 


GSKO Reject 


OTAR reject reason 


3 




M 




GSSI 


24 




M 




OTAR Retry Interval 


3 




M 




Address extension (see note) 


24 


2 







Proprietary element 




3 







NOTE: The address extension element shall be present only if the network code for which the provided GSKO 
relates is different to the serving network. 



A.3 PDUs for key association to GTSI 
A.3. 1 D-OTAR KEY ASSOCIATE demand 

Shall be used by SwMI to associate or disassociate a cipher key with one or more groups. 
• Direction: SwMI to MS; 



Service used: 



MM; 



• Response to: none; 

• Response expected: U-OTAR KEY ASSOCIATE STATUS or none. 

Table A.24: D-OTAR KEY ASSOCIATE demand contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


D-OTAR 


OTAR sub type 


4 


1 


M 


Key associate demand 


Acknowledgement flag 


1 


1 


M 


If "0" No acknowledgement required 


If "1" Acknowledgement required 


Explicit response 
(see note 3) 


1 


1 


M 


If "0" IVIS shall respond if state changes. 
If "1" IVIS shall always respond 


IVIax response timer value 


16 


1 


M 


Identifies the maximum period over which the MS will 
randomly choose to respond 


Key association type 


1 


1 


M 


SCK (0), GCK (1) 


SCK select number 


6 




C 


Provided if key type = SCK 


SCK subset grouping type 


4 




C 


Provided if key type = SCK 


GCK select number 


17 




C 


Provided if key type = GCK 


Number of groups 


5 


1 


M 


(0) reserved, (1 to 30) number of groups, (31) range of 
groups 


GSSI (see note 1) 


24 




C 


Repeated element 


Address extension 
(see note 2) 


24 


2 







NOTE 1 : The GSSI element is repeated; total number GSSI elements = value of "Number groups" element. 

For < Number of Groups < 31 ; = 2 for Number of Groups = 31 , and GSSI elements shall contain 

the lowest followed by the highest value GSSI in the range. GSSI can only be provided for a single 

network within the same PDU. 
NOTE 2: The address extension element is only present if the network code for which the provided GSSIs 

relate is different to the serving network. 
NOTE 3: The "explicit response" element is only valid if "Acknowledgment field" is set to "1 ". 
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A.3.2 U-OTAR KEY ASSOCIATE status 

Shall be used by MS to indicate successful association or disassociation of a cipher key with one or more groups. 
• Direction: MS to SwMI; 



Service used: 



MM; 



Response to: D-OTAR KEY ASSOCIATE DEMAND 

Response expected: none. 

Table A.25: U-OTAR KEY ASSOCIATE STATUS contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


U-OTAR 


OTAR sub type 


4 


1 


M 


Key associate status 


Key association type 


1 


1 


M 


SCK(O), GCK(1) 


SCK subset grouping type 


4 




C 


Provided if key type = SCK 


Key association status 


3 


1 


M 




Number of groups 


5 




C 


Provided if "Key association status" = "Address not 
valid", and indicates the number of GSSI fields that 
follow. Valid range = 1 to 30 


GSSI 


24 




C 


Provided if "Key association status" = "Address not 
valid". Element is repeated the number of times 
indicated by the value of the "Number of groups" 
element and contains each unknown address 


Address extension 
(see note) 


24 


2 







NOTE: Tlie address extension element is only present if the network code for which the provided GSSIs 
relate is different to the serving network. 



A.4 PDUs to synchronize key or security class change 
A.4.1 D-CK CHANGE demand 

Shall be used by SwMI to indicate a cipher key change either in the future or immediately. 

• Direction: SwMI to MS; 

• Service used: MM; 

• Response to: none; 

• Response expected: U-CK CHANGE RESULT or none. 
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Table A.26: D-CK CHANGE DEMAND contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


D-CK CHANGE DEMAND 


Acknowledgement flag 


1 


1 


M 


If "0" No acknowledgement required 


If "1" Acknowledgement required 


Change of Security Class 


2 


1 


M 




Key change type 


3 


1 


M 




SCK use 


1 




C 


Provided if key change type = SCK; "0" = TMO, 
"1" = DM0 


Number of SCKs changed 


4 




C 


Provided if key change type = SCK; 

(0000) indicates subset of SCKs; (1) to (1 1 1 1) indicate 

number of single SCKs to follow 


SCK subset grouping type 


4 




C 


Provided if SCK use = DMO and Number of SCKs 
changed = 


SCK subset number 


5 




C 


Provided if SCK use = DMO and Number of SCKs 
changed = 


SCK-VN 


16 




C 


Provided if SCK use = DMO and Number of SCKs 
changed = 


SCK data (see note 1 ) 


21 




C 


Provided if key change type = SCK; and Number of 
SCKs = 1 to 1 1 1 1 ; repeated element 


CCK-id 


16 




C 


Provided if key change type = CCK, or if key change 
type = "Class 3 CCK and GCK activation" 


Number of GCKs 
changed 


4 




C 


Provided if key change type = GCK; 
Reserved (OOOOj) 


GCK data (see note 1 ) 


32 




C 


Provided if key change type = GCK; 
repeated element 


GCK-VN 


16 




C 


Provided if key change type = All GCK, or if key change 
type = "Class 3 CCK and GCK activation" 


Time type 


2 


1 


M 




Slot number 


2 




C 


Provided if time type = Absolute IV 


Frame number 


5 




C 


Provided if time type = Absolute IV 


Multiframe number 


6 




C 


Provided if time type = Absolute IV 


Hyperframe number 


16 




C 


Provided if time type = Absolute IV 


Network time (see note 2) 


48 




C 


Provided if time type = network time 


NOTE 1 : The SCK data or GCK data elements are repeated; total number of SCK data or GCK data 

elements = value of "Number of SCKs changed" or value of "Number of GCKs changed" element. 
NOTE 2: As specified in EN 300 392-2 [2], clause 18.5.24. 



A.4.2 U-CK CHANGE result 

Shall be used by MS-MM to inform the SwMI that it has registered the required cipher key change. 

• Direction: MS to SwMI; 

• Service used: MM; 

• Response to: D-CK CHANGE DEMAND; 

• Response expected: none. 
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Table A.27: U-CK CHANGE RESULT contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


U-CK CHANGE RESULT 


Change of Security Class 


2 


1 


M 




Key change type 


3 


1 


M 


If "change of security class" is "transition to security 
class 1" then this element is set to "no cipher key" 


SCK use 


1 




C 


Provided if key change type = SCK; "0" = TMO, 
"1" = DM0 


Number of SCKs changed 


4 




C 


Provided if key change type = SCK; 

indicates the number of SCK data elements to follow 


SCK subset grouping type 


4 




C 


Provided if SCK use = DMO; and Number of SCKs = 


SCK subset number 


5 




C 


Provided if SCK use = DMO; and Number of SCKs = 


SCK-VN 


16 




C 


Provided If SCK use = DIVIO; and Number of SCKs = 


SCK data (see note) 


21 




C 


Provided if key change type = SCK; 
repeated element 


CCK-id 


16 




C 


Provided if key change type = CCK 


Number of GCKs 
changed 


4 




C 


Provided if key change type = GCK 


GCK data (see note) 


32 




C 


Provided if key change type = GCK; 
repeated element 


GCK-VN 


16 




C 


Provided if key change type = All GCK 


NOTE: The SCK data or GCK data elements are repeated to inform the SwMI of all keys that have been 
successfully selected. This may not be the same number as demanded by the SwIVII. 



A.4a PDUs to delete air interface keys in IVIS 
A.4a.1 D-OTAR KEY DELETE demand 

Shall be used by the SwMI to delete air interface key material from the MS. 

• Direction: SwMI to MS; 

• Service used: MM; 

• Response to: none; 

• Response expected: U-OTAR KEY DELETE RESULT or none. 
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Table A.27a: D-OTAR KEY DELETE demand contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


D-OTAR Key Delete Demand 


Key delete type 


3 


1 


M 




Number of SCKs deleted 


5 




C 


Provided if key delete type = (000) or (001), individual 

SCK(s) or members of a KAG; 

indicates number of SCKN elements to follow 


SCKN 


5 




C 


Provided if key delete type = (000) or (001), individual 
SGK(s) or members of a KAG; 
Repeated element, number of elements corresponds to 
value of Number of SCKs deleted element 


SCK subset grouping type 


4 




C 


Provided if key delete type = (010), SCK subset 


SCK subset number 


5 




C 


Provided if key delete type = (010), SCK subset; 
Value corresponds to subset number to be deleted 


Number of GCKs deleted 


4 




C 


Provided if key delete type = (100) individual GCK(s) 


GCKN 


16 




C 


Provided if key delete type = (100), individual GCK(s); 
Repeated element, number of elements corresponds to 
value of Number of GCKs deleted element 


Address extension (see 
note) 


24 


2 







NOTE: The address extension element shall be present only if the network code for which the deleted key 
relates is different to the serving network. 



NOTE: If key delete type = 001, members of a KAG, the MS shall delete all other SCKNs in other subsets that 
correspond with the SCKN listed for deletion by the SwMI in this PDU. 

A.4a.2 U-OTAR KEY DELETE result 

Shall be used by MS-MM to inform the SwMI that it has deleted the required cipher keys. 

• Direction: MS to SwMI; 

• Service used: MM; 

• Response to: D-OTAR Key Delete Demand; 

• Response expected: none. 
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Table A.27b: U-OTAR KEY DELETE result contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


D-OTAR Key Delete Result 


Key delete type 


3 


1 


M 




Number of SCKs deleted 


5 




C 


Provided if key delete type = (000) or (001), individual 
SCK(s) or members of a KAG; 
(00000) to (1 1 1 1 1 ) indicate number of individual SCKs 
to follow 


SCKN 


5 




C 


Provided if key delete type = (000) or (001), individual 
SCK(s) or members of a KAG; 
Repeated element, number of elements corresponds to 
value of Number of SCKs deleted element 


SCK subset grouping type 


4 




C 


Provided if key delete type = (010) or (001), SCK 
subset or members of a KAG 


SCK subset number 


5 




C 


Provided if key delete type = (010), SCK subset; 
Value corresponds to subset number to be deleted 


Number of GCKs deleted 


4 




C 


Provided if key delete type = (100) individual GCK(s) 


GCKN 


16 




C 


Provided if key delete type = (100), individual GCK(s); 
Repeated element, number of elements corresponds to 
value of Number of GCKs deleted element 


GSKO-VN 


16 




C 


Provided if key delete type = (110), GSKO 


Address extension (see 
note) 


24 


2 







NOTE: The address extension element sliall be present only if the network code for which the deleted key 
relates is different to the serving network. 



NOTE: If the MS sets key delete type = 001, members of a KAG, the MS shall indicate that all other SCKNs in 
other subsets that correspond with the SCKN listed in this PDU have been deleted. 



A.4b PDUs to obtain Air Interface Key Status 



A.4b.1 D-OTAR KEY STATUS demand 



Shall be used by the SwMI to discover the current numbers and versions of air interface keys held by an MS by means 
of a status enquiry. May be used to allow a SwMI to maintain a record of the MS keying state without needing to 
explicitly update the MS with new key material to force a response. 



Direction: 



SwMI to MS; 



• Service used: 

• Response to: 



MM; 



none; 



Response expected: U-OTAR Key Status Response or none. 
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Table A.27c: D-OTAR KEY STATUS demand contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


D-OTAR 


OTAR sub-type 


4 


1 


M 


Key Status Demand 


Acknowledgement flag 


1 


1 


M 


If "0" No acknowledgement required 


If "1" Acknowledgement required 


Explicit response 
(note) 


1 


1 


M 


If "0" MS shall respond if state changes. 
If "1" IVIS shall always respond 


IVIax response timer value 


16 


1 


M 


Identifies the maximum period over which the MS will 
randomly choose to respond 


Key status type 


3 


1 


M 




SCKN 


5 




C 


If Key status type = (000), SCK 


SCK subset grouping type 


4 




C 


If Key status type = (001 ), SCK subset 


SCK subset number 


5 




C 


If Key status type = (001 ), SCK subset 


GCKN 


16 




C 


If Key status type = (01 1), GCK 


Address extension (see 
note 2) 


24 


2 







NOTE 1 : The "explicit response" element is only valid if "Acknowledgment field" is set to "1 ". 
NOTE 2: The address extension element shall be present only if the network code for which the requested 
key relates is different to the serving network. 



A.4b.2 U-OTAR KEY STATUS response 

Shall be used by the MS to respond to the SwMI's request to report the current numbers and versions of air interface 
keys held by the MS. 



• Direction: 

• Service used 



MS to SwMI; 
MM; 

• Response to: D-OTAR Key Status Demand; 

• Response expected: none. 
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Table A.27d: U-OTAR KEY STATUS RESPONSE contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


U-OTAR 


OTAR sub-type 


4 


1 


M 


Key Status Response 


Key status type 


3 


1 


M 




SCK subset grouping type 


4 


1 


C 


Provided if key status type = (001), SCK subset 


SCK subset number 


5 




C 


Provided if key status type = (001 ), SCK subset 


Number of SCK status 


6 




C 


Provided if key status type = (000, 001 or 010), SCK, 
SCK subset or all SCKs 


SCK data 


21 




C 


Provided if key status type = (000, 001 or 010), SCK, 
SCK subset or all SCKs; 
repeated element 


Number of GCK status 


5 




C 


Provided if key status type = (01 1 or 100), GCK or all 
GCKs 


GCK data 


32 




C 


Provided if key status type = (01 1 or 100), GCK or all 

GCKs; 

repeated element 


Number of GSKO status 


2 




C 


Provided if key status type = (1 01 ), GSKO 


GSKO-VN 


16 




C 


Provided if key status type = (101), GSKO, 
repeated element 


Address extension (see 
note 4) 


24 


2 







NOTE 1 : The number of "SCK data" elements following the "Number of SCK status" element shall be the 

same as the value of the "Number of SCK status" element. If IVIS has no SCKs, or does not have 

the requested SCK, no "SCK data" elements shall be sent. 
NOTE 2: The number of "GCK data" elements following the "Number of GCK status" element shall be the 

same as the value of the "Number of GCK status" element. If the MS has no GCKs, or does not 

have the requested SCK, no "GCK data" elements shall be sent. 
NOTE 3: The number of "GSKO-VN" elements following the "Number of GSKO status" element shall be the 

same as the value of the "Number of GSKO status" element. If the MS has no GSKOs, no 

"GSKO-VN" elements shall be sent. 
NOTE 4: The address extension element shall be present only if the network code for which the requested 

key relates is different to the serving network 



A.5 Other security domain PDUs 

A.5.1 U-TEI PROVIDE 

Shall be used by MS-MM to inform the SwMI of its terminal equipment identifier. 

• Direction: MS to SwMI; 

• Service used: MM; 

• Response to: D-LOCATION UPDATE ACCEPT; 

• Response expected: none. 

Table A.28: U-TEI PROVIDE PDU contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


U-TEI PROVIDE 


TEI 


60 


1 


M 




SSI 


24 


1 


M 




Address extension 


24 


2 







Proprietary element 




3 
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A.5.2 U-OTAR PREPARE 



Shall be used by MS-MM to inform the SwMI that it intends to change to a new cell. 

• Direction: MS to SwMI; 

• Service used: MM; 

• Response to: none; 

• Response expected: D-OTAR NEWCELL. 

Table A.29: U-OTAR PREPARE 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


U-OTAR 


OTAR sub-type 


4 


1 


M 


OTAR PREPARE 


Location Area 


14 


1 


M 


The Location Area of the preferred 
neighbour cell 


CCK request flag 


1 


1 


M 




Proprietary element 




3 








A.5.3 D-OTAR NEWCELL 



Shall be used by SwMI to inform the MS of the result of the U-OTAR PREPARE exchange. 

• Direction: SwMI to MS; 

• Service used: MM; 

• Response to: U-OTAR PREPARE; 

• Response expected: none. 

Table A.30: D-OTAR NEWCELL 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


D-OTAR 


OTAR sub-type 


4 


1 


M 


OTAR NEWCELL 


DCK Forwarding Result 


1 


1 


M 




CCK provision flag 


1 


1 


M 




CCK information 


Varies 




C 




Proprietary element 




3 








A.5.4 D-OTAR CMG GTSI PROVIDE 

Shall be used by SwMI to provide a GTSI to be used for group addressed OTAR functions. 

• Direction: SwMI to MS; 

• Service used: MM; 

• Response to: none; 

• Response expected: U-OTAR CMG GTSI RESULT or none. 
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Table A.30a: D-OTAR CMG GTSI PROVIDE contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


D-OTAR 


OTAR sub type 


4 


1 


M 


CMG GTSI PROVIDE 


GSSI 


24 


1 


M 




Address extension 
(see note) 


24 


2 







NOTE: The address extension element is only present if the network code for which the provided GSSI 
relates is different to the serving network. 



A.5.5 U-OTAR CMG GTSI RESULT 



Shall be used by MS to indicate successful reception of a GSSI or GTSI to be used to receive group addressed OTAR 
functions. 



• Direction: 

• Service used: 

• Response to: 



MS to SwMI; 
MM; 

D-OTAR CMG GTSI PROVIDE 
• Response expected: none. 

Table A.30b: U-OTAR CMG GTSI RESULT contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


U-OTAR 


OTAR sub type 


4 


1 


M 


CMG GTSI RESULT 


GSSI 


24 


1 


M 




Address extension 
(see note) 


24 


2 







NOTE: The address extension element is only present if the network code for which the provided GSSI 
relates is different to the serving network. 



A.6 PDUs for Enable and Disable 



A.6.1 D-DISABLE 

This message is sent by the Infrastructure to indicate that the mobile station shall be disabled (permanently or 
temporarily). 



• Direction: 

• Service used 



SwMI to MS; 

MM; 

Response to: -; 

Response expected: U-DISABLE STATUS or U- AUTHENTICATION RESPONSE. 
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Table A.31 : D-DISABLE contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


D-DISABLE 


Intent/Confirm 


1 


1 


M 


Intent or confirm 


Disabling type 


1 


1 


M 


Temporary or permanent 


Equipment disable 


1 


1 


M 


Disable equipment 


TETRA Equipment Identity 


60 




C 


Present if equipment disable = 1 


Subscription disable 


1 


1 


M 


Disable subscription 


Address Extension 


24 




C 


Present if Subscription disable = 1 


SSI 


24 




C 


Present if Subscription disable = 1 


Authentication challenge 


160 


2 







Proprietary 




3 








A.6.2 D-ENABLE 



This message is sent by the Infrastructure to indicate that the mobile station shall be enabled after a disable. 

• Direction: SwMI to MS; 

• Service used: MM; 

• Response to: -; 

• Response expected: U-DISABLE STATUS or U- AUTHENTICATION RESPONSE. 

Table A.32: D-ENABLE contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


D-ENABLE 


Intent/Confirm 


1 


1 


M 


Intent or confirm 


Equipment enable 


1 


1 


M 


Enable of equipment 


TETRA Equipment Identity 


60 




C 


Present if equipment enable = 1 


Subscription enable 


1 


1 


M 


Enable of subscription 


Address Extension 


24 




C 


Present if Subscription enable = 1 


SSI 


24 




C 


Present if Subscription enable = 1 


Authentication challenge 


160 


2 







Proprietary 




3 








A.6.3 U-DISABLE STATUS 

This message is sent by the mobile station to inform the infrastructure of its response to an enable or disable request and 
its resulting status. 



• Direction: 

• Service used 



MS to SwMI; 

MM; 

Response to: D-DISABLE or D-ENABLE; 

Response expected: none. 
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Table A.33: U-DISABLE STATUS contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU Type 


4 


1 


M 


U-DISABLE STATUS 


Equipment status 


2 


1 


M 


Indicates disabled state of equipment 


Subscription status 


2 


1 


M 


Indicates disabled state of subscription 


Enable/Disable result 


3 


1 


M 




Address Extension 


24 


2 





Present only if in response to enable/disable of 
subscription 


SSI 


24 


2 





Present only if in response to enable/disable of 
subscription 


TETRA Equipment Identity 


60 


2 





Present only if in response to enable/disable of 
equipment 


Proprietary 




3 








A.7 MM PDU type 3 information elements coding 

The authentication mechanisms may be combined with the normal and SwMI-initiated registration procedures as shown 
in MSC scenarios in clause 4. Therefore, type 3 elements are defined which carry the authentication information and 
which can be appended to the MM registration PDUs. These type 3 elements shall be as defined in this clause. 



A.7.1 Authentication downlink 



This type 3 element shall be appended to D-LOCATION UPDATE ACCEPT to inform the MS about the result of an 
authentication procedure which has been combined with registration and/or to request that an MS supplies its TEI 
and/or to supply the MS with CCK information (class 3) or SCK information (class 2) for the cell to which it is 
registering. 

• Direction: SwMI to MS; 

• MM PDU: D-LOCATION UPDATE ACCEPT; 

• Response to: U-AUTHENTICATION RESPONSE; 

• Response expected: none. 

Table A.34: Authentication downlink element contents 



Information element 


Length 


Type 


C/O/M 


Remark 


Authentication result [R1] 


1 


1 


M 


Only valid for authentication exchanges 


TEI request flag 


1 


1 


M 




CK provision flag 


1 


1 


M 




CK provision information 


Varies 




C 


Provided if CK provision flag = TRUE 



A. 7. 2 Authentication uplink 



This type 3 element shall be appended to U-LOCATION UPDATE DEMAND when the MS combines a registration 
request with a request to authenticate the SwMI or when the MS requests the CCK (class 3) or SCK (class 2) 
information for the cell to which it is registering. 



• Direction: 

• MM PDU: 

• Response to: 



MS to SwMI; 

U-LOCATION UPDATE DEMAND; 

D-LOCATION UPDATE COMMAND or none; 



Response expected: D-AUTHENTICATION RESPONSE. 
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Table A.35: Authentication uplinl< element contents 



Information element 


Length) 


Type 


C/O/M 


Remark 


CK request flag 


1 


1 


M 


If this is TRUE then the CK requested shall 
be implied by the security class field in 
ciphering parameters 


Random challenge [RAND2] 


80 


2 








A. 8 PDU Information elements coding 

The encoding of the information elements and sub-elements for the PDUs described in clauses A. 1 to A.7, are given in 
the following clauses. The most significant bit of the values shown in the tables is transmitted first. 



A.8.1 Acknowledgement flag 



The acknowledgement flag element shall be used to indicate whether or not U-OTAR KEY ASSOCIATE RESULT is 
expected after sending D-OTAR KEY ASSOCIATE DEMAND, or U-CK CHANGE RESULT after D-CK CHANGE 
DEMAND, or U-OTAR SCK RESULT after D-OTAR SCK PROVIDE, or U-OTAR GCK RESULT after D-OTAR 
GCK PROVIDE. 

Table A.36: Acknowledgement flag element contents 



Information element 


Length 


Value 


Remark 


Acknowledgement flag 


1 


02 


No acknowledgement required 


12 


Acknowledgement required 



A.8.2 Address extension 

The Address Extension Element is defined in EN 300 392-2 [2], clause 16.10.L 

A. 8. 3 Authentication challenge 

The Authentication Challenge element shall contain the random seed and random challenge from the SwMI to the MS if 
authentication is to be used in the enable or disable procedure. 

Table A.37: Authentication challenge element contents 



Information sub element 


Length 


Type 


Remark 


Random challenge RAND1 


80 


1 




Random seed RS 


80 


1 





A.8.4 Authentication reject reason 

Authentication reject reason indicates why a demand for authentication is rejected. 

Table A.38: Authentication reject reason element contents 



Information element 


Length 


Value 


Remark 


Authentication reject reason 


3 


OOO2 


Authentication not supported 


others 


Reserved 
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A.8.5 Authentication result 

Authentication result indicates the success or failure of an authentication. If the authentication fails, this element gives 
the reason for failure. 

Table A.39: Authentication result element contents 



Information element 


Length 


Value 


Remark 


Authentication Result [R1 or R2] 


1 


02 


Autlientication failed 


12 


Authentication successful or no authentication 
currently in progress 



A. 8. 6 Authentication sub-type 

Authentication subtype identifies the specific PDU when PDU-type is 0000 (uplink) or 0001 (downlink). 

Table A.40: Authentication sub-type element contents 



Information element 


Length 


Value 


Remark 


Authentication sub-type (uplink) 


2 


OO2 


U-AUTHENTICATION DEMAND 


OI2 


U-AUTHENTICATION RESPONSE 


IO2 


U-AUTHENTICATION RESULT 


II2 


U-AUTHENTICATION REJECT 


Authentication sub-type (downlink) 


2 


OO2 


D-AUTHENTICATION DEMAND 


OI2 


D-AUTHENTICATION RESPONSE 


IO2 


D-AUTHENTICATION RESULT 


II2 


D-AUTHENTICATION REJECT 



A.8.7 CCK identifier 

The CCK identifier (CCK-id) is the numerical value associated with a version number of a common cipher key. 

Table A.41 : CCK Identifier element contents 



Information element 


Length 


Value 


Remark 


CCK Identifier 


16 


Any 





A.8.8 CCK information 



The CCK information element is defined as below. 



Table A.42: CCK information element contents 



Information element 


Length 


Type 


C/O/M 


Remark 


CCK identifier (CCK-id) 


16 




M 




Key type flag 


1 




M 


= Current, 1 = Future 


Sealed CCK (SCCK) 


120 




M 




CCK location area information 


2-216 




M 




Future key flag 


1 




M 


Always false if key type flag = future 


Sealed CCK (SCCK) 


120 




C 


If future key flag = true 
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A.8.9 CCK Location area information 

The CCK location area information element indicates how location area data is to be provided for any CCK. 
Table A.43: CCK Location area information element contents 



Information element 


Length 


Type 


C/O/M 


Remark 


Type 


2 


1 


M 


00 = All location areas 


01 = List is provided 


10 = LA-id mask is provided 


1 1 = Range of LA-ids is provided 


Location area list 


18-214 




C 


If Type = 01 


Location area bit masl< 


14 




C 


If Type = 1 


Location area selector 


14 




c 


If Type = 1 


Location area range 


28 




c 


If Type = 1 1 


NOTE: The mask is logically ANDed with the LA-id. If the result is equal to the selector, then LA-id is valid for the 
CCK. 



A.8.10 CCK request flag 



The CCK request flag is used to ask the SwMI to send the CCK in use in the location area to which the MS is 
attempting to register. 

Table A.44: CCK request flag element contents 



Information element 


Length 


Value 


Remark 


CCK request flag 


1 


02 


No CCK requested 


12 


CCK requested 



A.8.11 Change of security class 



The change of security class information element indicates to the MS that the current key change is, or is not, associated 
with a change in security class of the cell. 

Table A.45: Change of security class element contents 



Information element 


Length 


Value 


Remark 


Change of Security Class 


2 


OO2 


No change of security class 






OI2 


Transition to Security Class 1 






IO2 


Transition to Security Class 2 






II2 


Transition to Security Class 3 



A.8.12 Cipher parameters 



The cipher parameters element is used to negotiate SCKN and KSG in class 2 cells, and KSG in class 3 cells. In 
addition, when registering for SC3 operation, the MS shall indicate its support for TM-SCK OTAR, SDMO and 
DM-SCK OTAR, and GCK encryption/OTAR. 
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Table A.46: Cipher parameters element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


KSG number 


4 


1 


M 




Security class 


1 


1 


M 


Value = for= Class 2 
Value = 1 for= Class 3 


SCK number 


5 




C 


Provided if class 2 


TM-SCK OTAR (note) 


1 




C 


Provided if class 3: 
Value = if not supported 
Value = 1 if supported 


SDMO and DM-SCK OTAR (note) 


1 




C 


Provided if class 3: 
Value = if not supported 
Value = 1 if supported 


GCK encryption/OTAR (note) 


1 




c 


Provided if class 3: 
Value = if not supported 
Value = 1 if supported 


Reserved 


2 




c 


Provided if class 3, default value 


NOTE: These fields (TM-SCK-OTAR, SDMO and DM-SCK-OTAR, GCK encryption/OTAR) only have meaning on 
the uplink. On the downlink these fields shall be set to value "0". 



A.8.13 CK provision flag 

The CK provision flag is used to indicate that CK information is present in the PDU. 

Table A.47: CK provision flag element contents 



Information element 


Length 


Value 


Remark 


CK provision flag 


1 


02 


No CK information provided (FALSE) 


12 


CK information provided (TRUE) 



A.8.14 CK provisioning information 



The CK provisioning information element is used to indicate that either SCK information, CCK information or both are 
present in the PDU. 

Table A.48: CK provisioning information flag element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


SCK provision flag 


1 


1 


M 




SCK information 


Varies 




C 


If SCK provision flag = TRUE 


CCK provision flag 


1 


1 


M 




CCK information 


Varies 




C 


If CCK provision flag = TRUE 



A.8.15 CK request flag 



The CK request flag is used to ask the SwMl to send the CCK or SCK in use in the location area to which the MS is 
attempting to register. The type of key requested by the MS shall be inferred by the security class field in the ciphering 
parameters information element, contained within the same PDU as the CK request flag. 

Table A.49: CK request flag element contents 



Information element 


Length 


Value 


Remark 


CK request flag 


1 


02 


No CK requested 


12 


CK requested 
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A.8.16 Class Change flag 



The Class Change flag is used to indicate that the class to the SwMI is to change. 

Table A.50: Class Change flag element contents 



Information element 


Length 


Value 


Remark 


Class Change flag 


1 


02 


No Class change 


12 


Class change 



A.8.17 DCK forwarding result 



The purpose of the DCK forwarding result element is to indicate if the SwMI was able to forward DCK to the requested 
new cell. 

Table A.51 : DCK forwarding result element contents 



Information element 


Length 


Value 


Remark 


DCK Forwarding Result 


1 


02 


DCK forwarding failure 


12 


DCK forwarding successful 



A.8.18 Disabling type 



The purpose of the Disabling Type element shall be to indicate which of the disabling types (i.e. temporary or 
permanent) is requested. 

Table A.52: Disabling Type element contents 



Information element 


Length 


Value 


Remark 


Disabling Type 


1 


02 


Temporary 


12 


Permanent 



A.8.19 Enable/Disable result 



The purpose of the enable/disable result element shall be to indicate whether or not enabling or disabling was 

successful. 

Table A.53: Enable/Disable result element contents 



Information element 


Length 


Value 


Remark 


Enable/Disable result 


3 


OOO2 


Enable/disable successful 


OOI2 


Enable/disable failure, address mismatch 


01 O2 


Enable/disable failure, TEI mismatch 


OII2 


Enable/disable failure, TEI and address mismatch 


IOO2 


Enable/disable failure, authentication is required 


IOI2 


Enable/disable failure, encryption is required 


11 O2 


Enable/disable failure, encryption and 
authentication are required 


III2 


Enable/disable failure, authentication not supported 
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A.8.20 Encryption mode 



A.8.20.1 Class 1 cells 

In a cell supporting only class 1 the following values and interpretations shall apply. 

Table A.54: Encryption mode element in class 1 cell contents 



Information element 


Length 


Value 


Remark 


Encryption mode element 


2 


OO2 


PDU not encrypted 


Others 


Reserved 



A.8.20.2 Class 2 cells 

In a class 2 cell the following values and interpretations shall apply. 

Table A.55: Encryption mode element in class 2 cell contents 



Information element 


Length 


Value 


Remark 


Encryption mode element 


2 


OO2 


PDU not encrypted 


OI2 


Reserved 


IO2 


PDU encrypted, SCK-VN is even 


II2 


PDU encrypted, SCK-VN is odd 



A.8.20.3 Class 3 cells 

In a class 3 cell the following values and interpretations shall apply. 

Table A.56: Encryption mode element in class 3 cell contents 



Information element 


Length 


Value 


Remark 


Encryption mode element 


2 


OO2 


PDU not encrypted 


OI2 


Reserved 


IO2 


PDU encrypted, CCK-id is even 


II2 


PDU encrypted, CCK-id is odd 



A.8.21 Equipment disable 



The purpose of the equipment disable element shall be to indicate whether the equipment is to be disabled. 

Table A.57: Equipment disable element contents 



Information element 


Length 


Value 


Remark 


Equipment disable 


1 


O2 


Equipment not to be disabled 


I2 


Equipment to be disabled 
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A.8.22 Equipment enable 



The purpose of the Equipment enable element shall be to indicate whether the equipment is to be enabled. 

Table A.58: Equipment enable element contents 



Information element 


Length 


Value 


Remark 


Equipment enable 


1 


02 


Equipment not to be enabled 


12 


Equipment to be enabled 



A.8.23 Equipment status 



The piupose of the Equipment status element shall be to indicate the enabled or disabled state of the equipment. 

Table A.59: Equipment status element contents 



Information element 


Length 


Value 


Remark 


Equipment status 


2 


OO2 


Equipment enabled 


OI2 


Equipment temporarily disabled 


IO2 


Equipment permanently disabled 


II2 


Reserved 



A.8. 23a Explicit response 



The purpose of the explicit response element is to indicate whether the MS is required to acknowledge a key provision 
or key association explicitly, or conditionally on whether the transaction changes the MS state and provides a key, key 
version or key association that it did not already have. 

Table A.59a: Explicit response element contents 



Information element 


Length 


Value 


Remark 


Explicit response 


1 


O2 


Response to be sent only if state of MS is changed 


I2 


Response to be sent whether state changed or not 



A.8.24 Frame number 

Refer to EN 300 392-2 [2], clause 16.10.11. 

A.8.25 Future key flag 

The future key flag information element is defined in table A. 60. 

Table A.60: Future key flag information element contents 



Information element 


Length 


Value 


Remark 


Future key flag 


1 


O2 


Indicates that no future key data is provided 


I2 


Indicates that future key data is provided 
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A.8.26 GCKdata 



The GCK data information element is defined in table A.61. 

Table A.61 : GCK data information element contents 



Information element 


Length 


Type 


C/O/M 


Remark 


GCK Number 


16 


1 


M 




GCK Version number 


16 


1 


M 





A.8.27 GCK key and identifier 

The GCK key and identifier element is defined as in table A.62. 

Table A.62: GCK key and identifier element contents 



Information element 


Length 


Type 


C/O/M 


Remark 


GCKN 


16 


1 


M 




GCK version number 


16 


1 


M 




Sealed GCK (SGCK) 


120 


1 


M 





A.8.28 GCK Number (GCKN) 

The GCKN is the identifier for a GCK used to associate it to one or more groups. 

Table A.63: GCKN element contents 



Information element 


Length 


Value 


Remark 


GCKN 


16 


any 





A.8.28aGCK Provision result 

The GCK provision result indicates the result when provisioning a GCK using OTAR. 

Table A.63a: GCK Provision Result 



Information element 


Length 


Type 


C/O/M 


Remark 


GCK data 


32 


1 


M 




Provision result (GCK) 


3 


1 


M 




Current GCK Version number 


16 




C 


Defined as GCK-VN and sent when provision 
result has value incorrect key-VN 


NOTE: The address extension element is only present if the network code for which the provided GSSI relates is 
different to the serving network. 
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A.8.28bGCK rejected 

The GCK rejected element is defined in table A. 63b. 



Table A.63b: GCK rejected element contents 



Information element 


Length 


Type 


C/O/M 


Remark 


OTAR reject reason 


3 


1 


M 




Group association 


1 


1 


M 




GCKN 


16 




C 


If Group association = GCKN 


GSSI 


24 




C 


If Group association = GSSI 



A.8.29 GCK select number 

The GCKN contained in OTAR key associate messages to indicate either which key should be associated with the 
signalled group(s); or whether no key should be associated and existing key disassociated. 

Table A.64: GCK select number element contents 



Information element 


Length 


Value 


Remark 


GCK select number 


17 


to (216-1) 


GCK number (GCKN) selected 


216 


No GCKN selected 


(2^6+1) 


GCKN disassociated 


(2^6 + 2) to 
(217-1) 


Reserved 



A.8.29aGCK Supported 

The GCK Supported information element is found in the SYSINFO broadcast message and indicates to the MS whether 
or not GCKs are supported on the current cell. 

Table A.64a: GCK Supported information element in SYSINFO 



Information element 


Length 


Value 


Remark 


GCK Supported 
(See note) 


1 





GCK not supported on this cell 


1 


GCK supported on this cell 


NOTE: If the "Air interface encryption service" element in the BS service details element 

contained in the D-MLE SYSINFO PDU contains value 0, "Service is not available on 
this cell", then the value of this element has no meaning. This element is only valid if 
the security information element in SYSINFO, sub-element Security class 2 or 3 is set 
to "Security class 3 is supported on this cell" 



A.8.30 GCK Version Number (GCK-VN) 

The GCK-VN shall be used in the GCK OTAR mechanism to uniquely identify a key by version number. 

Table A.65: GCK-VN element contents 



Information element 


Length 


Value 


Remark 


GCK-VN 


16 


any 
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A.8.31 Group association 



The group association element determines whether the provided GCK is for association with one specific group, or for 
association with all groups linked to a specific GCKN. 

Table A.66: Group association element contents 



Information element 


Length 


Value 


Remark 


Group association 


1 


02 


Associated with GCKN 


12 


Associated witli specific GSSI 



A.8.32 GSKO Version Number (GSKO-VN) 

The GSKO-VN shall be used in the group addressed OTAR mechanism to uniquely identify a key version number. 
Table A.67: GSKO Version Number (GSKO-VN) element contents 



Information element 


Length 


Value 


Remark 


GSKO-VN 


16 


any 





A.8.33 GSSI 

See EN 300 392-1 [1], clause 7. 

A.8.34 Hyperframe number 

Refer to EN 300 392-2 [2]. 

A.8.35 Intent/confirm 

The purpose of the Intent/confirm element shall be to indicate whether the enable or disable command is the first intent, 
always used with or without authentication, or the confirmation once successful authentication has been carried out. 

Table A.68: Intent/confirm element contents 



Information element 


Length 


Value 


Remark 


Intent/confirm 


1 


02 


Intent 


12 


Confirm 
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A.8.36 Void 

A.8.37 Key association status 

The key association status is sent by the MS to the SwMI to indicate the resuh of the key association Protocol exchange. 

Table A.69: Key association result element contents 



Information element 


Length 


Value 


Remark 


Key association status 


3 


OOO2 


Association carried out as requested 


OOI2 


Key not valid 


01 O2 


Address not valid 


OII2 


Association rejected 


Others 


Reserved 



A.8.38 Key association type 



Key association type identifies the type of key to be associated to a group. 

Table A.70: Key association type information element contents 



Information element 


Length 


Value 


Remark 


Key association type 


1 


O2 


SCK 


I2 


GCK 



A. 8. 39 Key change type 

Key change type identifies the type of key to be changed using the CK CHANGE protocol. 

Table A.71 : Key change type information element contents 



Information element 


Length 


Value 


Remark 


Key change type 


3 


OOO2 


SCK 


OOI2 


CCK 


01 O2 


GCK 


OII2 


Class 3 CCK and GCK activation 


IOO2 


All GCKs 


IOI2 


No cipher key 


IIO2 


Reserved 


III2 


Reserved 



£75/ 



148 



ETSI TS 100 392-7 V2.4.1 (2006-10) 



A.8.39aKey delete type 



Key delete type identifies the type of key and organization of keys, where applicable, to be deleted by the D-OTAR Key 
Delete Demand PDU. 

Table A.71a: Key delete type information element contents 



Information element 


Length 


Value 


Remark 


Key delete type 


3 


OOO2 


Individual SCK{s) 


001 2 


IVIembers of a KAG 


01 O2 


SCK subset 


0112 


All SCKs 


1002 


Individual GCK(s) 


1012 


All GCKs 


1102 


GSKO 


1112 


Reserved 



A.8.39bKey Status type 



Key status type identifies the type of key and organization of keys, where applicable, of which the SwMI is requesting 
status, or of which the MS is providing the status. 

Table A.71b: Key status type information element contents 



Information element 


Length 


Value 


Remark 


Key status type 


3 


OOO2 


Individual SGK{s) 


OOI2 


SCK subset 


01 O2 


All SCKs 


OII2 


Individual GCK(s) 


IOO2 


All GCKs 


IOI2 


GSKO 


IIO2 


Reserved 


III2 


Reserved 



A.8.40 Key type flag 



Table A.72: Key type flag information element contents 



Information element 


Length 


Value 


Remark 


Key type flag 


1 


O2 


Current 


I2 


Future 



£75/ 



149 



ETSI TS 100 392-7 V2.4.1 (2006-10) 



A.8.41 KSG-number 



KSG number identifies the encryption algorithm in use. 



Table A.73: KSG Number element contents 



Information element 


Length 


Value 


Remark 


KSG Number 


4 


OOOO2 


TETRA Standard Algorithm, TEA1 


0001 2 


TETRA Standard Algorithm, TEA2 


001 O2 


TETRA Standard Algorithm, TEAS 


0011 2 


TETRA Standard Algorithm, TEA4 


01002to011l2 


Reserved for future expansion 


I2XXX 


Proprietary TETRA Algorithms 



A.8.42 Location area 

See EN 300 392-2 [2], clause 16. 

A.8.43 Location area bit mask 

The location area bit mask element provides an indication of location areas. 

Table A.74: Location area bit mask element contents 



Information element 


Length 


Value 


Remark 


Location area bit mask 


14 


any 


Mask to be logically ANDed with LA-id for CCK 
distribution 



A.8.44 Location area selector 

The location area selector is used in conjunction with the location area bit mask element to provide an indication of 
location areas. 

Table A.75: Location area selector element contents 



Information element 


Length 


Value 


Remark 


Location area selector 


14 


any 


Bit pattern for comparison with local LA-id 



A.8.45 Location area list 

The location area list element provides a list of location areas. 

Table A.76: Location area list element contents 



Information element 


Length 


Type 


C/O/M 


Remark 


Number of location areas 


4 


1 


M 




Location area 


14 




C 


See note 


NOTE: The Location area element shall be repeated as many times as indicated by the Number of location areas 
element. 
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A.8.46 Location area range 



The location area range element provides a list of location areas that runs from Low Location Area value to High 
Location Area value. 

Table A.77: Location area range element contents 



Information element 


Length 


Value 


Remark 


Low Location Area value (LLAV) 


14 


to 214-1 


Lowest value of LA-id for which CCK is valid 


High Location Area value (HLAV) 


14 


1 to 214-1 


Highest value of LA-id for which CCK is valid 


NOTE : H LAV shal 1 always be g reater that LLAV. | 



A.8.46aMax response timer value 



The max response timer value element is used to set the maximum period over which an MS shall randomly choose a 
response time to a group addressed OTAR, key status or key association command. 

Table A.77a: Max response timer value element contents 



Information element 


Length 


Value 


Remark 


IVIax response timer value 


16 





Immediate response, for individually 
addressed transactions 


1 to 2^6-1 


Value in seconds from 1 to 65 535 



A.8.47 IVIobile country code 

See EN 300 392-1 [1], clause 7. 

A.8.48 IVIobile network code 

See EN 300 392-1 [1], clause 7. 

A.8.49 Multiframe number 

See EN 300 392-2 [2]. 

A.8.50 Mutual authentication flag 

The Mutual Authentication Identifier is used to indicate whether or not mutual authentication elements are included in 
the PDU. 

Table A.78: Mutual authentication flag element contents 



Information element 


Length 


Value 


Remark 


Mutual authentication flag 


1 


02 


Mutual authentication elements included = FALSE 


12 


Mutual authentication elements included = TRUE 



A. 8. 51 Network time 

See EN 300 392-2 [2], clause 18.5.24. 
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A.8.52 Number of GCKs changed 



The Number of GCKs changed element indicates how many group cipher keys were changed in the OTAR protocol. 

Table A.79: Number of GCKs changed element contents 



Information element 


Length 


Value 


Remark 


Number of GCKs changed 


4 


OOOO2 


No GCKs changed 


0001 2 


1 GCK changed 


001 O2 


2 GCKs changed 


0011 2 


3 GCKs changed 


OIOO2 


4 GCKs changed 


Others 


Etc. up to 15 GCKs changed 



A.8.52aNumber of GCKs deleted 

The Number of GCKs deleted element indicates how many group cipher keys are to be or were deleted by the MS in the 
OTAR Key Delete protocol. 

Table A.79a: Number of GCKs deleted element contents 



Information element 


Length 


Value 


Remark 


Number of GCKs deleted 


5 


OOOOO2 


No GCKs deleted 


0000l2to1111l2 


1 to 31 GCKs deleted 



A.8.52bNumber of GCK status 

The Number of GCK status element indicates how many group cipher keys' status information are being provided by 
the MS. 

Table A.79b: Number of GCK status element contents 



Information element 


Length 


Value 


Remark 


Number of GCK status 


5 


OOOOO2 


MS has no GCKs, no GCK data 
element follows 


0000l2tO IIIII2 


1 to 31 GCK's' data is provided 



A.8. 52c Number of GCKs provided 

The Number of GCKs provided element indicates how many group cipher keys there are to follow in the PDU. 
Table A.79c: Number of GCKs provided element contents 



Information element 


Length 


Value 


Remark 


Number of GCKs provided 


3 


OOO2 


No GCKs provided 


OOI2 


1 GCK provided 


01 O2 


2 GCKs provided 


OII2 


3 GCKs provided 


IOO2 


4 GCKs provided 


IOI2 


5 GCKs provided 


IIO2 


6 GCKs provided 


III2 


7 GCKs provided 
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A.8.52d Number of GCKs rejected 

The Number of GCKs rejected element indicates how many group cipher keys are requested by the MS. 
Table A.79d: Number of GCKs rejected element contents 



Information element 


Length 


Value 


Remark 


Number of GCKs rejected 


3 


OOO2 


Reserved 


001 2 


1 GCK rejected 


01 O2 


2 GCKs rejected 


0112 


3 GCKs rejected 


1002 


4 GCKs rejected 


1012 


5 GCKs rejected 


1102 


6 GCKs rejected 


1112 


7 GCKs rejected 



A.8.52e Number of GCKs requested by GCKN 

The Number of GCKs requested by GCKN element indicates how many group cipher keys are requested by the MS 
referenced by GCKN. 

Table A.79e: Number of GCKs requested by GCKN element contents 



Information element 


Length 


Value 


Remark 


Number of GCKs requested by GCKN 


3 


OOO2 


GCKs requested 


001 2 


1 GCK requested 


01 O2 


2 GCKs requested 


0112 


3 GCKs requested 


1002 


4 GCKs requested 


1012 


5 GCKs requested 


1102 


6 GCKs requested 


1112 


7 GCKs requested 



A.8.52f Number of GCKs requested by GSSI 

The Number of GCKs requested by GSSI element indicates how many group cipher keys are requested by the MS 
referenced by GSSI. 

Table A.79f : Number of GCKs requested by GSSI element contents 



Information element 


Length 


Value 


Remark 


Number of GCKs requested by GSSI 


3 


OOO2 


GCKS requested 


001 2 


1 GCK requested 


01 O2 


2 GCKs requested 


0112 


3 GCKs requested 


1002 


4 GCKs requested 


1012 


5 GCKs requested 


1102 


6 GCKs requested 


1112 


7 GCKs requested 
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A.8.53 Number of groups 

The Number of groups element indicates how many GSSI elements there are to follow in the PDU. 

Table A.80: Number of groups element contents 



Information element 


Length 


Value 


Remark 


Number of groups 


5 


OOOOO2 


Reserved. 


OOOOIjto IIIIO2 


Number of GSSIs 


IIIII2 


Range of GSSIs (see notes 1 and 2) 


NOTE 1 : Range of GSSIs will be indicated by a lower and a higher value. 

NOTE 2: Value 11111 is not valid when used in U-OTAR Key Associate Status PDU and when used in Group 
Identity Security Related Information Element. 



A.8.53aNumber of GSKO status 

The Number of GSKO status element indicates how many group session keys for OTARs' status information are being 
provided by the MS. 

Table A.80a: Number of GSKO status element contents 



Information element 


Length 


Value 


Remark 


Number of GSKO status 


2 


OO2 


IVIS has no GSKO, no GSKO data element 
follows 


0l2to1l2 


1 to 3 GSKOs' data is provided 



A. 8. 54 Number of location areas 



The Number of location areas element indicates how many location area elements there are to follow in the PDU. 

Table A.81 : Number of location areas element contents 



Information element 


Length 


Value 


Remark 


Number of location areas 


4 


OOOO2 


Reserved 


000l2tO IIII2 


1 to 15 location areas 



A.8.55 Number of SCKs changed 



The Number of SCKs changed element indicates how many static cipher keys were changed in the OTAR protocol. 

Table A.82: Number of SCKs changed element contents 



Information element 


Length 


Value 


Remark 


Number of SCKs changed 


4 


OOOO2 


No SCKs changed 


OOOI2 


1 SCK changed 


001 O2 


2 SCKs changed 


OOII2 


3 SCKs changed 


OIOO2 


4 SCKs changed 


010l2tO IIII2 


5 to 15 SCKs changed 
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A.8.55aNumber of SCKs deleted 

The Number of SCKs deleted element indicates how many static cipher keys are to be or were deleted by the MS in the 
OTAR Key Delete protocol. 

Table A.82a: Number of SCKs deleted element contents 



Information element 


Length 


Value 


Remark 


Number of SCKs deleted 


5 


OOOOO2 


No SCKs deleted 


0000l2to1111l2 


1 to 31 SCKs deleted 



A.8.56 Number of SCKs provided 

The Number of SCKs provided element indicates how many static cipher keys there are to follow in the PDU. 

Table A.83: Number of SCKs provided element contents 



Information element 


Length 


Value 


Remark 


Number of SCKs provided 


3 


OOO2 


No SCKs provided 


OOI2 


1 SCK provided 


01 O2 


2 SCKs provided 


OII2 


3 SCKs provided 


IOO2 


4 SCKs provided 


IOI2 


5 SCKs provided 


IIO2 


6 SCKs provided 


III2 


7 SCKs provided 



A.8.56aNumber of SCKs rejected 

The Number of SCKs rejected element indicates how many static cipher keys there are to follow in the PDU. 
Table A.83a: Number of SCKs rejected element contents 



Information element 


Length 


Value 


Remark 


Number of SCKs rejected 


3 


OOO2 


No SCKs rejected 


OOI2 


1 SCK rejected 


01 O2 


2 SCKs rejected 


OII2 


3 SCKs rejected 


IOO2 


4 SCKs rejected 


IOI2 


5 SCKs rejected 


IIO2 


6 SCKs rejected 


III2 


7 SCKs rejected 
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A.8.57 Number of SCKs requested 

The Number of SCKs requested element indicates how many static cipher keys are requested by the MS. 
Table A.84: Number of SCKs requested element contents 



Information element 


Length 


Value 


Remark 


Number of SCKs requested 


3 


OOO2 


Reserved 


001 2 


1 SCK requested 


01 O2 


2 SCKs requested 


0112 


3 SCKs requested 


1002 


4 SCKs requested 


1012 


5 SCKs requested 


1102 


6 SCKs requested 


1112 


7 SCKs requested 



A.8.57aNumber of SCK status 

The Number of SCK status element indicates how many static cipher keys' status information are being provided by 
the MS. 

Table A.84a: Number of SCK status element contents 



Information element 


Length 


Value 


Remark 


Number of SCK status 


6 


OOOOOO2 


MS has no SCKs, no SCK data element 
follows 


000001 2 to1000002 


1 to 32 SCKs' data is provided 


10000l2to IIIIII2 


Reserved 



A.8.57bOTAR reject reason 



The OTAR reject reason element indicates the reason that the SwMI does not supply the requested key. 

Table A.84b: OTAR reject reason element contents 



Information element 


Length 


Value 


Remark 


OTAR reject reason 


3 


OOO2 


Key not available 


001 2 


Invalid key number 


01 O2 


Invalid address 


0112 


KSG number not supported 


others 


Reserved 
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A.8.57cOTAR retry interval 



The OTAR retry interval information element indicates how many hyperframes the MS shall wait before retrying an 
OTAR Demand for SCK, GSKO or GCK. 

Table A.84c: OTAR retry interval element contents 



Information element 


Length 


Value 


Remark 


OTAR retry interval 


3 


OOO2 


Do not retry 


001 2 


Wait 1 liyperframe 


01 O2 


Wait 2 liyperframes 


0112 


Wait 4 tiyperframes 


1002 


Wait 8 liyperframes 


1012 


Wait 16 liyperframes 


1102 


Wait 32 liyperframes 


1112 


Wait 64 hyperframes 



A.8.58 OTAR sub-type 



The OTAR sub-type indicates whether the PDU is a demand or provide for CCK, SCK, GCK or GSKO keys or the 
result of a key transfer. 

Table A.85: OTAR sub-type element contents 



Information element 


Length 


Value 


Remark 


OTAR sub-type 


4 


OOOO2 


CCK Demand (uplinl<) or 
CCK Provide (downlinl<) 


0001 2 


CCK Result (uplink) or 
CCK Reject (downlink) 


001 O2 


SCK Demand (uplink) or 
SCK Provide (downlink) 


0011 2 


SCK Result (uplink) or 
SCK Reject (downlink) 


OIOO2 


GCK Demand (uplink) or 
GCK Provide (downlink) 


OIOI2 


GCK Result (uplink) or 
GCK Reject (downlink) 


OIIO2 


Key associate Demand (downlink) or 
Key associate Status (uplink) 


OIII2 


OTAR Prepare (Uplink) or 
OTAR NEWCELL (downlink) 


IOOO2 


GSKO Demand (uplink) or 
GSKO Provide (downlink) 


1001 2 


GSKO Result (uplink) or 
GSKO Reject (downlink) 


IOIO2 


Key delete demand (downlink) or 
Key delete status (uplink) 


IOII2 


Key status demand (downlink) or 
Key status response (uplink) 


IIOO2 


CMG GTSI provide (downlink) or 
CMG GTSI result (uplink) 


110l2tO IIII2 


Reserved 
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A.8.59 PDUtype 



The PDU type indicates the MM PDU type for all the security PDUs including the authentication and OTAR PDUs. 
The PDU types in the following table are taken from the unused or security-reserved values of PDU type in the MM 
protocol. For more details, see EN 300 392-2 [2], clause 16. 

Table A.86: PDU type element contents 



Information element 


Length 


Value 


Downlink Assignment 


Uplink Assignment 


PDU Type 


4 


OOOO2 


D-OTAR 


U-AUTHENTICATION 


0001 2 


D-AUTHENTICATION 




001 O2 


D-CK CHANGE DEMAND 




0011 2 


D-DISABLE 




OIOO2 


D-ENABLE 


U-CK CHANGE RESULT 


OIOI2 




U-OTAR 


1001 2 




U-TEI PROVIDE 


IOII2 




U-DISABLE STATUS 



NOTE: Values not shown on both uplink and downlink are assigned to other PDU types, which are given in 

EN 300 392-2 [2], clause 16.10.39. 

A.8.60 Proprietary 

See EN 300 392-2 [2] table 120a. 

A.8.61 Provision result 

The provision result is sent by the MS to the SwMI to indicate whether or not the MS was able to decrypt the sealed key 
(CCK, SCK, GCK or GSKO). 

Table A.87: Provision result element contents 



Information element 


Length 


Value 


Remark 


Provision result 


3 


OOO2 


Sealed key accepted 


OOI2 


Sealed key failed to decrypt 


01 O2 


Incorrect key number (e.g. SCKN, GCKN) 


OII2 


OTAR rejected 


IOO2 


Incorrect Key version number 
(e.g. SCK-VN, GCK-VN, CCK-id) 


IOI2 


Identified GSKO-VN not present 


11 O2 


KSG number not supported 


Others 


Reserved 



A.8.62 Random challenge 



The random challenge is an 80-bit number used as the input to the authentication algorithm, from which a response is 
calculated. 

Table A.88: Random challenge element contents 



Information element 


Length 


Value 


Remark 


Random challenge [RAND1 or RAND2] 


80 


Any 
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A.8.63 Random seed 

The random seed is an 80-bit number used as the input to the session key generation algorithm, which is used in the 
authentication processes. 

Table A.89: Random seed element contents 



Information element 


Length 


Value 


Remark 


Random seed (RS) 


80 


Any 





A.8.64 Random seed for OTAR 

The random seed for OTAR (RSO) is an 80-bit number used as the input to the session key for OTAR generation 
algorithm when sealing GCK, GSKO and SCK. Only one random seed is used per D-OTAR PDU, irrespective of the 
number of keys contained in the PDU. It is only provided from SwMI to MS. 

Table A.90: Random seed element contents 



Information element 


Length 


Value 


Remark 


Random seed for OTAR (RSO) 


80 


Any 





A.8.65 Void 



Table A.91 : Void 



A.8.66 Response value 

The response value is the value returned by the challenged party, calculated from the random challenge. 

Table A.92: Response value element contents 



Information element 


Length 


Value 


Remark 


Response Value (RES1 or RES2) 


32 


Any 





A.8.67 SCK data 



The SCK data information element is defined in table A. 93. 

Table A.93: SCK data information element contents 



Information element 


Length 


Type 


C/O/M 


Remark 


SCK Number 


5 


1 


M 




SCK Version number 


16 


1 


M 
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A.8.68 SCK information 



The SCK information element is defined in table A.94. 



Table A.94: SCK information element contents 



Information element 


Length 


Type 


C/O/M 


Remark 


Session key 


1 


1 


M 


Identifies if encrypted with group or individual 
encryption session key 


Random seed for OTAR 


80 




C 


Provided if session key for individual 


GSKO-VN 


16 




C 


Provided if session key for group 


SCK number (SCKN) 


5 


1 


M 




SCK version number (SCK-VN) 


16 


1 


M 




Sealed SCK (SSCK) 


120 


1 


M 




Future l<ey flag 


1 


1 


M 




SCK number (SCKN) 


5 




C 


If future key flag = true 


SCK version number (SCK-VN) 


16 




C 


If future key flag = true 


Sealed SCK (SSCK) 


120 




c 


If future key flag = true 



A.8.69 SCK key and identifier 



The SCK key and identifier contains the sealed SCK which is identified by the SCK number. 

Table A.95: SCK key and identifier element contents 



Information element 


Length 


Type 


C/O/M 


Remark 


SCKN 


5 


1 


M 




SCK version number (SCK-VN) 


16 


1 


M 




SCK use 


1 


1 


M 


If '0' Trunked Mode Operation 
If '1' Direct IVIode Operation 


Reserved 


1 


1 


M 


For future expansion 


Sealed key (SSCK) 


120 


1 


M 





A.8.70 SCK Number (SCKN) 



The SCK number is a five-bit value associated with an SCK. Where multiple SCKs are transferred, this element is 
repeated with each SCK number related to the SCKs being transferred. 

Table A.96: SCK number element contents 



Information element 


Length 


Value 


Remark 


SCK number 


5 


OOOOO2 


SCK number 1 


00001 2 


SCK number 2 


etc.etc 


SCK numbers in turn 


IIIOI2 


SCK number 30 


IIIIO2 


Class 2: SCK number 31; 
Class 3: fallback SCK number 31 


IIIII2 


Class 2: SCK number 32; 
Class 3: fallback SCK number 32 
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A.8.71 SCK number and result 

The SCK number and result contains the resuh of the SCK key transfer for the key identified by the SCK number. 

Table A.97: SCK number and result element contents 



Information element 


Length 


Type 


C/O/M 


Remark 


SCK number (SCKN) 


5 


1 


M 




Provision result (SCK) 


3 


1 


M 




Current SCK Version number 


16 




C 


Defined as SCK-VN and sent wtien provision 
result has value incorrect key-VN 



A.8.72 SCK provision flag 



The SCK provision flag is used to indicate that SCK information is present in the PDU. 

Table A.98: SCK provision flag element contents 



Information element 


Length 


Value 


Remark 


SCK provision flag 


1 


02 


No SCK information provided (FALSE) 


12 


SCK information provided (TRUE) 



A.8.72aVoid 

Table A.gg: Void 

A.8.72bSCK rejected 

The SCK rejected element is defined as in table A.99a. 

Table A.99a: SCK rejected element contents 



Information element 


Length 


Type 


C/O/M 


Remark 


OTAR reject reason 


3 


1 


M 




SCK number (SCKN) 


5 


1 


M 





A.8.73 SCK select number 

The SCK select number is contained in OTAR key associate messages to indicate either which key should be associated 
with the signalled group(s); or whether no key should be associated and any existing key disassociated. It is also used to 
indicate which keys have been selected in result PDUs. Where SCKs have been grouped into subsets, association with a 
single SCK shall automatically associate the group or groups with the other corresponding SCK members of other 
subsets. The SCKN selected shall be taken from the first subset only, i.e. the subset with SCKN = 1 as its lowest value. 

Table A.100: SCK select number element contents 



Information element 


Length 


Value 


Remark 


SCK select 


6 


0000002to01111l2 


SCK number (SCKN) selected 


IOOOOO2 


No SCKN selected 


100001 2 


SCKN dissociated 


1000102to11111l2 


Reserved 
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A.8.73aSCK subset grouping type 



The SCK subset grouping type element is contained in OTAR key associate messages where the SCK set is split into 
2 or more subsets. It allows the MS to associate multiple associated SCKs in different SCK subsets with the same group 
or groups. 

Table A.IOOa: SCK subset grouping type element contents 



Information element 


Length 


Value 


Remark 


SCK subset grouping type 


4 


OOOO2 


SCKs grouped into 1 subset of 30 l<eys 


OOOI2 


SCKs grouped into 2 subsets of 15 l<eys 


001 O2 


SCKs grouped into 3 subsets of 10 l<eys 


OOII2 


SCKs grouped into 4 subsets of 7 l<eys 


OIOO2 


SCKs grouped into 5 subsets of 6 l<eys 


OIOI2 


SCKs grouped into 6 subsets of 5 l<eys 


011 O2 


SCKs grouped into 7 subsets of 4 l<eys 


01112 


SCKs grouped into 1 subsets of 3 l<eys 


10002 


SCKs grouped into 1 5 subsets of 2 l<eys 


1001 2 


SCKs grouped into 30 subsets of 1 l<ey 


10102 


SCK grouping not valid, used to indicate a 
mismatcli in l<ey deletion or subset activation 
conditions 


101l2tO IIII2 


Reserved 



A.8.73bSCK subset number 

The SCK subset number element is contained in CK Change Demand messages where the SCK set is split into 2 or 
more subsets and a complete subset is to be made active. It indicates the number of the subset that is to be activated. 

Table A.IOOb: SCK subset number element contents 



Information element 


Length 


Value 


Remark 


SCK subset number 


5 


OOOOO2 


Mismatched number, used to indicate a 
mismatch in grouping when responding to a key 
status or delete demand 


0000l2tO IIIIO2 


Subset 1 to 30, value indicates number of 
subset 


IIIII2 


Reserved 


NOTE 1 : SCK subset number element value shall not be greater than the highest number of subsets 

permitted by the grouping signified by the SCK subset group number element. 
NOTE 2: SCK subset number = 1 corresponds to subset where lowest SCKN = 1 . 



A.8.74 SCK use 

The SCK use information element indicates if the SCK being provided is intended for use in Trunked Mode Operation 
or for use in Direct Mode Operation. 

Table A.101 : SCK version number element contents 



Information element 


Length 


Value 


Remark 


SCK use 


1 


O2 


Trunked Mode Operation 




I2 


Direct Mode Operation 
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A.8.75 SCK version number 

The SCK Version Number (SCK-VN) is the numerical value associated with a version number of a key being 
transferred in an OTAR SCK transaction. Multiple SCK-VNs shall be sent where multiple keys are transferred, one 
SCK-VN per key. 

Table A.102: SCK version number element contents 



Information element 


Length 


Value 


Remark 


SCK version number 


16 


Any 





A.8.76 Sealed Key (Sealed CCK, Sealed SCK, Sealed GCK, 
Sealed GSKO) 

The Sealed Key is the key transferred by an OTAR transaction, in a protected (encrypted) manner. 

Table A.103: Sealed Key element contents 



Information element 


Length 


Value 


Remark 


Sealed Key 


120 


Any 





A.8.77 Security information element 



The Security information element is found in the SYSINFO broadcast message and indicates to the MS the current 
security capabilities of the cell. 

Table A.104: Security information element in SYSINFO 



Information element 


Length 


C/O/M 


Value 


Remark 


Authentication 
(see note 4) 




M 


02 


Authentication not required on this cell 


12 


Authentication required on this cell 


Security Class 1 
(see note 1) 




M 


02 


Security Class 1 MS not supported on this cell 


12 


Security Class 1 MS supported on this cell 


Security Class 2 or 3 
(see note 1) 




M 


02 


Security Class 2 MS supported on this cell 


12 


Security Class 3 MS supported on this cell 


SCKN (see notes 1 and 2) 


5 


C 




If Security Class 2 MS supported on this cell 


DCK retrieval during initial 

Cell selection (see notes 1 and 3) 




C 


02 


Service not supported 


12 


Service supported 


DCK retrieval during cell 
Re-selection (see notes 1 and 3) 




C 


02 


Service not supported 


12 


Service supported 


Linked GCK crypto-periods 
(see note 3 and 5) 




C 


02 


Service not supported 


12 


Service supported 


Short GCK-VN 
(see notes 3 and 6) 


2 


C 




Represents the 2 least significant bits of the 
GCK-VN associated with the linked GCKs. 


NOTE 1 : If the "Air interface encryption service" element in the BS service details element contained in the D-MLE 

SYSINFO PDU contains value 0, "Service is not available on this cell", then the value of this element has no 

meaning. 
NOTE 2: If Security Class 2 MS supported on this cell. 
NOTE 3: If Security Class 3 MS supported on this cell. 

NOTE 4: An MS that does not support authentication should not select a cell that broadcasts "authentication required" 
NOTE 5: If the "GCK Supported" information element in SYSINFO indicates "GCK not supported on this cell" then the 

value of this element has no meaning. 
NOTE 6: If the "Linked GCK crypto-periods" information element indicates "Service not supported" then the value of 

this element has no meaning. 
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A.8.78 Session key 



The Session key element indicates whether a key has been sealed using a Group Session Key for OTAR known to 
members of a group, or sealed with a Session Key for OTAR (KSO) which is individually generated by an MS. 

Table A.105: Session key element contents 



Information element 


Length 


Value 


Remark 


Session key 


1 


02 


Sealed key has been generated using 
individually generated session key KSO for MS 


12 


Sealed key has been generated using Group 
Session Key for OTAR known to group of MSs 



A.8.79 Slot Number 

See EN 300 392-2 [2], clause 7. 

A.8.80 SSI 

See EN 300 392-1 [1], clause 7. 

A.8.81 Subscription disable 

The purpose of the Subscription disable element shall be to indicate whether the subscription is to be disabled. 

Table A.I 06: Subscription disable element contents 



Information element 


Length 


Value 


Remark 


Subscription disable 


1 


02 


Subscription not to be disabled 


12 


Subscription to be disabled 



A.8.82 Subscription enable 



The purpose of the Subscription enable element shall be to indicate whether the subscription is to be enabled. 

Table A.I 07: Subscription enable element contents 



Information element 


Length 


Value 


Remark 


Subscription enable 


1 


02 


Subscription not to be enabled 


12 


Subscription to be enabled 



A.8.83 Subscription status 



The purpose of the Subscription status element shall be to indicate the enabled or disabled state of the subscription. 

Table A.I 08: Subscription status element contents 



Information element 


Length 


Value 


Remark 


Subscription status 


2 


OO2 


Subscription enabled 


OI2 


Subscription temporarily disabled 


IO2 


Subscription permanently disabled 


II2 


Reserved 
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A.8.84 TEI 

This is the terminal equipment identifier of the MS. For a full definition see EN 300 392-1 [1], clause 7. The definition 
given here expands that given in EN 300 392-1 [1], clause 7 for encoding of TEI for transmission over the radio 
interface. 

Table A.109: TEI contents 



Information element 


Length 


Value 


Remark 


Terminal equipment identifier digit #1 


4 


Any 




Terminal equipment identifier digit #2 


4 


Any 




Terminal equipment identifier digit #3 


4 


Any 




Terminal equipment identifier digit #4 


4 


Any 




Terminal equipment identifier digit #5 


4 


Any 




Terminal equipment identifier digit #6 


4 


Any 




Terminal equipment identifier digit #7 


4 


Any 




Terminal equipment identifier digit #8 


4 


Any 




Terminal equipment identifier digit #9 


4 


Any 




Terminal equipment identifier digit #1 


4 


Any 




Terminal equipment identifier digit #1 1 


4 


Any 




Terminal equipment identifier digit #1 2 


4 


Any 




Terminal equipment identifier digit #1 3 


4 


Any 




Terminal equipment identifier digit #1 4 


4 


Any 




Terminal equipment identifier digit #1 5 


4 


Any 





A.8.85 TEI request flag 



This bit indicates whether the MS should supply the TEI. 

Table A.110: TEI request flag contents 



Information element 


Length 


Value 


Remark 


TEI request flag 


1 


02 


Do not supply TEI 


12 


Supply TEI 



A.8.85aTimeshare cell and Al encryption information 

Table A.llOa: Timeshare cell and Al encryption information element 



Information element 


Type 


Length 


Value 


Remark 


Discontinuous mode/AI 
encryption information 


M 


2 


OO2 


Al encryption information 


Others 


Defined in EN 300 392-2 [2], table 255 


Authentication flag 
(see note 2) 


M 


1 


O2 


Authentication not required on this cell 


I2 


Authentication required on this cell 


Class 1 


M 


1 


O2 


IVIS of security class 1 not supported on this cell 


I2 


IVIS of security class 1 supported on this cell 


Security class 2 or 3 
(see notes 1 and 3) 


M 


1 


O2 


IVIS of security class 2 supported on this cell 


I2 


IVIS of security class 3 supported on this cell 


NOTE 1 : Security class 2 and security class 3 are mutually exclusive. 

NOTE 2: If the "Air interface encryption service" element in the BS service details element contained in the D-MLE 

SYSINFO PDU and in D-NWRK BROADCAST PDUs contains value 0, "Service is not available on this cell", 

then the value of this element has no meaning. 
NOTE 3: This field is ignored if BS Service Details indicate no support of Al encryption. 
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A.8.86 Time type 

The time type element indicates what form time is expressed in the PDU. 

Table A.111 : Time type information element contents 



Information element 


Length 


Value 


Remark 


Time type 


2 


OO2 


Absolute IV 


OI2 


Network time 


IO2 


Immediate, first slot of first frame of next multiframe 


II2 


Currently in use 



A.8.87 Type 3 element identifier 



The type 3-element identifier indicates the MM type 3 elements to be used in the MM PDUs for authentication and 
OTAR purposes. The type 3 element identifiers in the following table are identified in the present document only and 
are taken from the reserved values of type 3 element identifier defined in the MM protocol. For more details, 
see EN 300 392-2 [2], clause 16. 

Table A.112: Type 3 element identifier element contents 



Information element 


Length 


Value 


Remarks 


Type 3 element identifier 


4 


1001 2 


Autlientication uplinl< 


IOIO2 


Authentication downlinl< 
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Annex B (normative): 

Boundary conditions for the cryptographic algorithms and 

procedures 

In the following the symbol IXYZI shall be used to denote the length of the parameter XYZ. If the length of a parameter 
can vary, IXYZI denotes the range between the shortest and the longest possible values for XYZ. 

TAll: Shall be used to compute KS from K and RS. The algorithm shall have the following properties: 

• Input 1: Bit string of length IKI; 

• Input 2: Bit string of length IRS I; 

• Output: Bit string of length IKSI. 

The algorithm should be designed such that it is difficult to infer any information about Input 1 from the knowledge of 
Input 2 and the Output (even if the details of the algorithm are known). 

TA21: shall be used to compute the KS' from K and RS. The algorithm shall have the following properties: 

• Input 1: Bitstringof length IKI; 

• Input 2: Bit string of length IRS I; 

• Output: Bit string of length IKS'l. 

The algorithm should be designed such that it is difficult to infer any information about Input 1 from the knowledge of 
Input 2 and the Output (even if the details of the algorithm are known). 

TAll: shall be used to compute (X)RESl as well as DCKl from KS and RANDl. The algorithm shall have the 
following properties: 

• Input 1: Bitstringof length IKSI; 

• Input 2: Bit string of length IRAND II; 

• Output 1 : Bit string of length l(X)RES 1 1; 

• Output 2: Bit string of length IDCKl I. 

The algorithm should be designed such that it is difficult to infer any information about Input 1 or Output 2 from the 
knowledge of Input 2 and Output 1 (even if the details of the algorithm are known). 

TA22: shall be used to compute (X)RES2 as well as DCK2 from KS' and RAND2. The algorithm shall have the 
following properties: 

• Input 1: Bit string of length IKS'l; 

• Input 2: Bit string of length IRAND2I; 

• Output 1 : Bit string of length l(X)RES2l; 

• Output 2: Bit string of length IDCK2I. 

The algorithm should be designed such that it is difficult to infer any information about Input 1 or Output 2 from the 
knowledge of Input 2 and Output 1 (even if the details of the algorithm are known). 
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TA31: shall be used to compute SCCK from CCK, CCK-id and DCK. The algorithm shall have the following 
properties: 



Input 1: 
Input 2: 
Input 3: 
Output: 



Bit string of length ICCKI; 
Bit string of length ICCK-idI; 
Bit string of length IDCKI; 
Bit string of length ISCCKI. 



The algorithm should be designed such that it is difficult to infer any information about Input 1 from the knowledge of 
Input 2 and the Output, provided that Input 3 is unknown (even if the details of the algorithms are known). 

TA32: shall be used to compute CCK from SCCK, CCK-id and DCK. The algorithm shall have the following 
properties: 



• Input 1: 


Bit string of length ISCCKI; 


• Input 2: 


Bit string of length IDCKI; 


• Input 3: 


Bit string of length ICCK-idI; 


• Output 1: 


Bit string of length ICCKI; 


• Output 2: 


Boolean. 



The algorithm should be designed such that it is difficult to find for a fixed Input 2 a value for Input 1 and Input 3 that 
results in Output 2 assuming the value "FALSE", provided that Input 2 is unknown (even if the details of the algorithms 
are known). Moreover, it shall be difficult to derive (parts of) Input 2 from the observation of various matching values 
of other inputs and outputs (known plain text attack). 

TA41: shall be used to compute KSO from K and RSO. The algorithm shall have the following properties: 

• Input 1: Bit string of length IKI; 

• Input 2: Bit string of length IRSOI; 

• Output 1: Bit string of length IKSOI. 

The algorithm should be designed such that it is difficult to infer any information about Input 1 from knowledge of 
input 2 and the output (even if details of the algorithm are known). 

TA51: shall be used to compute SSCK from SCK, SCKN, SCK-VN, and KSO. The algorithm shall have the following 
properties: 



Input 1: 
Input 2: 
Input 3: 
Input 4: 
Output: 



Bit string of length ISCKI; 
Bit string of length ISCK-VNI; 
Bit string of length IKSOI; 
Bit string of length ISCKNI; 
Bit string of length ISSCKI. 



The algorithms should be designed such that it is difficult to infer any information about Input 1 or Input 4 from the 
knowledge of Input 2 and the Output, provided that Input 3 is unknown (even if the details of the algorithm are known). 
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TA52: shall be used to compute SCK and SCKN from SSCK, SCK-VN and KSO. The algorithm shall have the 
following properties: 



• Input 1: 


Bit string of length ISSCKI; 


• Input 2: 


Bit string of length IKSOI; 


• Input 3: 


Bit string of length ISCK-VNI; 


• Output 1: 


Bit string of length ISCKI; 


• Output 2: 


Boolean; 


• Output 3: 


Bit string of length ISCKNI. 



The algorithm should be designed such that it is difficult to find for a fixed Input 2 values for Input 1 and Input 3 that 
result in Output 2 assuming the value FALSE, provided that Input 2 is unknown (even if the details of the algorithm are 
known). Moreover, it shall be difficult to derive (parts of) Input 2 from the observation of various matching values of 
other inputs and outputs (known plain text attack). 

TA61: shall be used to compute xESI from xSSI and either SCK or CCK. The algorithm shall have the following 
properties: 

• Input 1: Bit string of length ICCKI; 

• Input 2: Bit string of length ISSII; 

• Output 1: Bit string of length lESII. 

The algorithm should be designed such that it is difficult to infer any knowledge of Input 1 from observation of various 
matching values of other input 2s and outputs. Further it should be difficult to infer any knowledge of Input 2 from 
observation of various matching values of other input 2s and outputs. Moreover, for a fixed input 1 different values of 
Input 2 shall always give different values of the output. 

TA71: shall be used to compute MGCK from GCK and CCK. The algorithm shall have the following properties: 

• Input 1 : Bit string of length IGCKI; 

• Input 2: Bit string of length ICCKI; 

• Output 1: Bit string of length IMGCKI. 

The algorithm should be designed such that it is difficult to infer any information about Input 1 from knowledge of 
input 2 and the output (even if details of the algorithm are known), and also designed such that it is difficult to infer any 
information about Input 2 from knowledge of input 1 and the output (even if details of the algorithm are known). 

TA81: shall be used to compute SGCK from GCK, GCKN, GCK-VN and KSO. The algorithm shall have the following 
properties: 

Input 1 : Bit string of length IGCKI; 

Input 2: Bit string of length IGCK-VNI; 

Input 3: Bit string of length IKSOI; 

Input 4: Bit string of length IGCKNI; 

Output: Bit string of length ISGCKI. 

The algorithm should be designed such that it is difficult to infer any information about Input 1 from the knowledge of 
Input 2, Input 4, and the Output, provided that Input 3 is unknown (even if the details of the algorithms are known). 
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TA82: shall be used to compute GCK and GCKN from SGCK, GCK-VN, and KSO. The algorithm shall have the 
following properties: 



• Input 1: 


Bit string of length ISGCKI; 


• Input 2: 


Bit string of length IKSOI; 


• Input 3: 


Bit string of length IGCK-VNI; 


• Output 1: 


Bit string of length IGCKI; 


• Output 2: 


Boolean. 


• Output 3: 


Bit string of length IGCKNI; 



The algorithm should be designed such that it is difficult to find for a fixed Input 2 values for Input 1 and Input 3 that 
result in Output 2 assuming the value "FALSE", provided that Input 2 is unknown (even if the details of the algorithms 
are known). Moreover, it shall be difficult to derive (parts of) Input 2 from the observation of various matching values 
of other inputs and outputs (known plain text attack). 

TA91: shall be used to compute SGSKO from GSKO, GSKO-VN and KSO. The algorithm shall have the following 
properties: 



Input 1: 
Input 2: 
Input 3: 
Output: 



Bit string of length IGSKOI; 
Bit string of length IGSKO-VNI; 
Bit string of length IKSOI; 
Bit string of length ISGSKOI. 



The algorithm should be designed such that it is difficult to infer any information about Input 1 from the knowledge of 
Input 2 and the Output, provided that Input 3 is unknown (even if the details of the algorithms are known). 

TA92: shall be used to compute GSKO from SGSKO, GSKO-VN, and KSO. The algorithm shall have the following 
properties: 



• Input 1: 


Bit string of length ISGSKOI; 


• Input 2: 


Bit string of length IKSOI; 


• Input 3: 


Bit string of length IGSKO-VNI; 


• Output 1: 


Bit string of length IGSKOI; 


• Output 2: 


Boolean. 



The algorithm should be designed such that it is difficult to find for a fixed Input 1 values for Input 3 that result in 
Output 2 assuming the value "FALSE", provided that Input 2 is unknown (even if the details of the algorithms are 
known). Moreover, it shall be difficult to derive (parts of) Input 2 from the observation of various matching values of 
other inputs and outputs (known plain text attack). 

The following algorithms, TBI, TB2 and TB3 may be used to generate K locally to an MS but do not directly alter the 
air interface. 

TBI: shall be used to compute K from AC. The algorithm shall have the following properties: 

• Input: Bit string of length lACI; 

• Output: Bit string of length IKI. 

The algorithm should be designed such that the Output is dependent on every bit of the Input. 
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TB2: shall be used to compute K from UAK. The algorithm shall have the following properties: 

• Input: Bit string of length lUAKI; 

• Output: Bit string of length IKI. 

The algorithm should be designed such that the Output is dependent on every bit of the Input. 

TB3: shall be used to compute K from UAK and AC. The algorithm shall have the following properties: 

• Input 1: Bit string of length lACI; 

• Input 2: Bit string of length lUAKI; 

• Output: Bit string of length IKI. 

The algorithm should be designed such that the Output is dependent on every bit of both Inputs. 

TB4: shall be used to compute DCK from DCKl and DCK2. The algorithm shall have the following properties: 

• Input 1 : Bit string of length IDCKl I; 

• Input 2: Bit string of length IDCK2I; 

• Output: Bitstringof length IDCKl. 

The algorithm should be designed such that the Output is dependent on every bit of both Inputs. 

TBS: shall be used to compute ECK from CK, CC, CN (see EN 300 392-2 [2], clause 21.5) and LA. The algorithm 
shall have the following properties: 

Input 1 : Bit string of length ICKI; 

Input 2: Bit string of length ILAI; 

Input 3: Bit string of length ICNI; 

Input 4: Bit string of length ICCI; 

Output: Bit string of length lECKI. 

The algorithm should be designed such that the Output is dependent on every bit of all Inputs. 
TB6: Reserved for DMO Security (EN 300 396-6 [5]). 
TB7: shall be used to compute EGSKO from GSKO. The algorithm shall have the following properties: 

• Input: Bit string of length IGSKOI; 

• Output: Bit string of length lEGSKOI. 

The algorithm should be designed such that the Output is dependent on every bit of the Input. 
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B.1 Dimensioning of the cryptographic parameters 

Table B.l shows the lengths of the cryptographic parameters given in annex B. 

Table B.1 : Dimensioning of cryptographic parameters 



Abbreviation 


No. of bits 


AC 


16 to 32 


CC 


6 


CCK 


80 


CCK-id 


16 


CK 


80 


CN 


12 


DCK 


80 


DCK1 


80 


DCK2 


80 


ECK 


80 


EGSKO 


128 


ESI 


24 


GCK 


80 


GCKN 


16 


GCK-VN 


16 


GSKO 


96 


GSKO-VN 


16 


K 


128 


KS 


128 


KS' 


128 


KSO 


128 


LA 


14 


MF 


1 


MGGK 


80 


PIN 


16 to 32 


RAND1 


80 


RAND2 


80 


RES1 


32 


RES2 


32 


RS 


80 


RSO 


80 


SOCK 


120 


SCK 


80 


SCKN 


5 


SCK-VN 


16 


SGGK 


120 


SGSKO 


120 


SSCK 


120 


SSI 


24 


UAK 


128 


XRES1 


32 


XRES2 


32 
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B.2 Summary of the cryptographic processes 

A summary of the authentication mechanisms explained in the previous clauses is given in figures B.l and B.2. Only 
the paths where keys are generated by an algorithm are shown. 
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NOTE: Algorithms TBI , TB2 and TBS are shown for information and may be used in deriving K within an IVIS. 
Figure B.l : Overview of air interface authentication and Itey management (sheet 1 of 2) 
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Figure B.2: Overview of air interface authentication and key management (sheet 2 of 2) 
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Annex C (normative): 
Timers 

C.1 T354, authorization protocol timer 

The value of T354 shall be 30 seconds. 

C.2 T371 , Delay timer for group addressed delivery of 
SCK and GCK 

T371 is a timer with a value in seconds randomized to fall within the range 1 and the SwMI-supplied "max response 
timer value" (which can be given a value from 1 to 65 535, i.e. 18,2 hours). 

C.3 T372, Key forwarding timer 

The value of T372 shall be 5 seconds. 
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Annex E (informative): 
Change request history 

The following CRs have been incorporated in the present document. 



CR 


Date 


Version 


Short description 


Status 


102 


17-3-05 


V2.2.1 


Redundant Key Change Type Values 


WG6 approved 


103 


1 7-3-05 


V2.2.1 


Definition of security related information and group identity 
security related information element 


WG6 approved 


105 


17-3-05 


V2.2.1 


Incorporating CIVIG GTSI within D-OTAR GSKO Provide 


WG6 approved 


106 


10-5-05 


V2.2.1 


Authentication during enable disable 


WG6 approved 


107 


10-5-05 


V2.2.1 


Modifications to OTAR mechanisms 


WG6 approved 


109 


10-5-05 


V2.2.1 


Re-specification of SGK information element 


WG6 approved 


110 


16-6-05 


V2.2.1 


Modified use of cipher parameters 


WG6 approved 


111 


13-10-05 


V2.2.1 


Actions following authentication failure 


WG6 approved 


115 


13-10-05 


V2.2.1 


Addition of 6.7.1 .4, Handling of PDUs not-conforming to link 
ciphering mode 


WG6 approved in 
online editing 


117 


10-3-06 


V2.3.0 


Definition of 'ignore' in 6.7.1 .4 to be refined 


WG6 approved 


118 


4-5-06 


V2.3.0 


Inclusion of OTAR RETRY Interval element in D-OTAR-xxx- 
Reject PDUs 


WG6 approved 


119 


4-5-06 


V2.3.0 


Correction of OTAR PDUs use of network codes 


WG6 approved 


121 


29-6-06 


V.2.3.1 


Inclusion of OTAR RETRY Interval element in D-OTAR-xxx- 
Reject PDUs 


WG6 approved 


122 


29-6-06 


V.2.3.1 


Correction of OTAR SCK PROVIDE PDUs: use of SCK Use 
element 


WG6 approved 


123 


20-9-06 


V2.3.1 


Correction to U-OTAR-GCK DEMAND PDU and PDU encoding of 
element lengths 


WG6 approved 
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